PR# 13903 ECF: library completeness and name clashes
Problem Report Summary
Submitter: ericbe
Category: Other
Priority: Medium
Date: 2008/01/21
Class: Bug
Severity: Serious
Number: 13903
Release: 6.2.7.1786
Confidential: No
Status: Open
Responsible:
Environment: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; InfoPath.1; .NET CLR 3.0.04506.648)
Synopsis: ECF: library completeness and name clashes
Description
I read the documentation about ECF libraries in: http://dev.eiffel.com/Libraries Considering a library as being a collection of functionalities exported by an interface is fine. What I don't like is the fact that this notion of interface is not complete in ECF. Let's consider a class as being exported if it can be used by the "clients" of a library L. As far as I can understand a class is not exported by L if it is marked as hidden or if it is declared in another library used by library L as client. When I say that the notion of interface is not complete is that L may offer to its clients access to an exported class A which itself uses a non-exported class B in the signature of one of its exported routines. This is generally the source of confusion, especially when reading error messages, when the client declares its own version of class B. Now about name clashes and conflits. What I could understand in this section is that as long as a class is not exported (i.e. not visible from the client), no action needs to be taken. And of course if there is a name clash between two classes exported from two different libraries, then we need to resolve it using prefixing or renaming. If we have a look at ECMA Eiffel, we see: 8.3.3: A universe is a set of classes. 8.3.5: VSCN: It is valid for a universe to include a class if and only if no other class of the universe has the same upper name. The interesting thing is that if we restrict the universe to be a set classes locally declared or exported from other libraries, then we can consider a library as a universe (i.e. set of classes that can be used in the library classes) and also as a way to combine different universes (by taking into account only exported classes of the other libraries it depends on). With this notion, we could reconcile ECMA Eiffel and ECF, and it would therefore be reasonable to consider that Gobo could support ECF. Unfortunately EiffelStudio does not implement ECF the way it is described in this documentation. Even if there is a name clash between two classes exported from two different libraries, EiffelStudio will report an error only if this class is actually used in the client of these two libraries. This is very unfortunate. In your experience, how often does it happen that two classes with the same name exported by two different libraries are not used in the client? In other words, if EiffelStudio were to be changed to report a name cash error in this case, how many extra explicit renamings would people have to do on average?
To Reproduce
Problem Report Interactions