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