This site contains older material on Eiffel. For the main Eiffel page, see http://www.eiffel.com.

NICE Language Committee: libraries

From swissoft.h.provi.de!eiffel@Hannover.POP.DE Tue Oct 24 12:01:47 1995
Date: 24 Oct 1995 19:39:00 +0200
To: bertrand@eiffel.com
Cc: fhart@atlanta.twr.com
Cc: jcm@mstr.hgc.edu
Cc: tynor@atlanta.twr.com
Subject: Libraries and class renaming
X-Mailer: XP v3.02 R/C4131
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Content-Length: 2561
X-Lines: 55
Status: RO

Dear colleagues,

recently, Bertrand and I were talking about our (SiGs) new library
concept and about class renaming. I said that we've managed to deal
with class renaming in our new release. Unfortunately,it turned out
that this is not the case and we've decided to cancel the feature. I don't
want to go into the details, especially because I assume that
you know what the problems with class renaming are. However, I'm
now convinced that a clean solution requires the concept of a
library as an entity in its own right and some means to specify
how libraries are related.

Eiffel/S 2.0 has a library concept (i.e. single 'clusters' don't exist any
more - systems are build from libraries, not individual classes or
clusters) but I think it would be worth the effort to develop a library
concept which addresses class nameclashes, etc.

This is of course not the most urgent problem but it is important
to realize that

a) Libraries play a central role in the Eiffel 'philosophy'.
   Therefore they should somehow become first class citizens.
b) Using libraries from different vendors in one single system
   will become increasingly important.
c) To have or have not a common view of what libraries are
   and how they should be described and handled is an important
   aspect of interoperability.

With respect to c) I must say that adopting LACE for Eiffel/S 2.0
was impossible. LACE emphasizes clusters and classes and has no
concept of a library as a higher structuring mechanism. Perhaps,
this time, we can try to develop a common concept before divergence
even starts. The fact that Eiffel/S 2.0 has a library concept
cannot be taken as beeing contradictory to the previous sentence:
We're prepared to change the concept (and actually it's far away
from what I have in mind).

Again, this is not urgent but I'd like to hear your comments.

With best regards,
        Michael

p.s.: (almost unrelated to the above)
      In my opinion it would be a severe mistake to try to
      standardize LACE. My main objections are 1) see above
      and 2) the fact that LACE requires runtime options to be
      specified at compile time (i.e. whether certain assertions
      in certain classes will be checked or not). Eiffel/S
      has proven that runtime options can be specified separately
      and that no recompilation whatsoever is necessary to turn
      assertions (or debug instructions) on or off.

SwisSoft, Michael Schweitzer      Geismar Landstr. 16  D-37083 Goettingen
Fax : +49 551 770 35 44           email : eiffel@swissoft.h.provi.de


From tynor@atlanta.twr.com Tue Oct 24 12:51:05 1995
Date: Tue, 24 Oct 95 15:20:57 EDT
To: eiffel@swissoft.h.provi.de (Michael Schweitzer)
Cc: bertrand@eiffel.com, fhart@atlanta.twr.com, jcm@mstr.hgc.edu
Subject: re: Libraries and class renaming
References: <5wSH7SRULdB@swissoft.h.provi.de>
Content-Length: 1662
X-Lines: 31
Status: RO

Without getting into what I expect to be a contentious debate over the
efficacy of Lace, I agree with Michael that some sort of first-class
clustering mechanism is required in order to mix and match "libraries"
of independently developed Eiffel classes (within Tower, we've been
using the term "meta cluster" (for named collections of clusters) rather
than "library", but I suspect that our concepts of what that would
involve is similar).  Even something as simple as the Common Lisp
"package" would go a long way towards avoiding namespace collisions
between libraries.

Class renaming as suggested by the Lace chapter in ETL * is not
practical for incrementally compiled implementations (we have a workable
design but it's ugly and would require some additional non-Eiffel /
non-Lace files to be supplied by the end-user and/or library
developer). Not to mention that it's _confusing_ to the reader of the
software text who has to mentally translate, "... Mnnn... it says
WINDOW, but I'm looking at class FOO which is in cluster BAR which has a
rename clause which renames WINDOW to BAZ_WINDOW, so this is really a
BAZ_WINDOW..." **).  Much better, I think, to provide a language mechanism
for grouping classes and allowing qualified access to them (so, we'd use
something like BAZ.WINDOW directly in the .e file rather than requiring
extra-lingual namespace gymnastics.

Steve

* I say "suggested" since I'm not aware that any of us have managed to
implement it...

** Please don't nitpick if I've gotten the order of renaming and whether
the client or supplier cluster does the renaming wrong -- it's been some
time since I studied the Lace renaming stuff.