jos@cs.vu.nl (12/19/88)
Hello to everybody on this brand new newsgroup. I hope we will have
some useful discussions on this group.
Happy Christmas, happy new year and now to the point:
----------------------------------------------------------------------
I have some questions about the usage of generic parameters.
In the basic eiffel library there is a class TREE[T],
which has one generic parameter: T.
In Bertrand Meyer's book there is an example about a hierarchic
window class. On page 284 the example looks like:
class WINDOW export ..... inherit
TREE
rename
child as subwindow,
parent as superwindow,
insert_child as insert_subwindow, etc.
...
WINDOW inherits class TREE, but it does not specify the generic
parameter of TREE.
Questions:
1. Is this correct Eiffel? (I can't find anything in the book about it)
2a. If it is, what are the semantics of this kind of inheritance ?
2b. If it is not, how should the WINDOW class inherit TREE ?
Possible answers:
1+2a. This is correct Eiffel, and we have the following situation:
local
t : TREE ;
w : WINDOW ;
dummy : ??? ;
w.Create;
t = w; -- allowed, because w is an heir to t.
-- t.value can not be used, because its type is still generic T
-- the next call will always be rejected by the compiler,
-- no matter what the type of dummy is.
dummy = t.value;
1+2b. This is not correct Eiffel, and the correct definition
of the class WINDOW should be:
class WINDOW export ..... inherit
TREE[WINDOW]
rename
child as subwindow,
parent as superwindow,
insert_child as insert_subwindow, etc.
...
If we have an object w of type WINDOW, then w.child should be
the same as w.child_value. This looks suspicious, so I think
this is not the right solution.
Jos Warmer
jos@cs.vu.nl
PS. We have ordered the compiler, but it hasn't arrived yet.
So I can't try it out. This is not too bad, now I actually
have to *think* about it.bertrand@hub.ucsb.edu (Bertrand Meyer) (12/20/88)
(Citations from the original have been condensed.) > Hello to everybody on this brand new newsgroup. At my end of the world your message was #1. Congratulations. > In the basic Eiffel library there is a generic class TREE [T]; > [but] on page 284 of B. Meyer's book the example looks like: > > class WINDOW export ..... inherit TREE [...] > > 1. Is this correct Eiffel? (I can't find anything in the book about it) > 2a. If it is, what are the semantics of this kind of inheritance ? > 2b. If it is not, how should the WINDOW class inherit TREE ? > Possible answers: > 1+2a. This is correct Eiffel [...] > 1+2b. This is not correct, and the correct definition should be > class WINDOW export ..... inherit TREE [WINDOW] [...] > [Then] if we have an object w of type WINDOW, then w.child should be > the same as w.child_value. This looks suspicious, so I think > this is not the right solution. In a way both anwers are correct. The example in the book is ``correct Eiffel'' if we assume a non-generic class TREE; this is what I did in the book in order to keep the example simple (this may not have been so clever considering that it confuses those careful readers who, as Jos did, compared with the actual library). With respect to class TREE as it exists in the actual library, however, the class is obviously incorrect. (This raises the question of whether the basic Eiffel library is part of the language definition. The example clearly assumes that it is not.) Solution 1+2b is then the correct one; properties close to the one mentioned by Jos (w.child = w.child_value) should be put in as clauses of the class invariant. Too bad you didn't have access to the actual system; then you could have seen that solution 1.2b is indeed used in the graphical library (class GEN_WINDOW). The class actually inherits from TREE [like Current] for more flexibility. (It seems that the two relevant invariant clauses have been commented out, for no apparent reason, in release 2.1. They will be put back in release 2.2.) Obviously in the next edition of the book the example should either conform to the actual TREE class from the library, or use another class name. At that time, however, the library should be fully standardized and its key elements made part of the language definition, so the first solution appears to be the best. Thank you for pointing out the problem. Bertrand Meyer bertrand@eiffel.com
UH2@PSUVM.BITNET (Lee Sailer) (12/21/88)
In article <1826@vlot.cs.vu.nl>, jos@cs.vu.nl says: > >In Bertrand Meyer's book there is an example about a hierarchic >window class. On page 284 the example looks like: > > class WINDOW export ..... inherit > TREE > rename > child as subwindow, > parent as superwindow, > insert_child as insert_subwindow, etc. > ... > >WINDOW inherits class TREE, but it does not specify the generic >parameter of TREE. > I dunno Eiffel, but this looks enough like Simula that I'll give you the Simula answer 8-) In your example, the WINDOW class *does* inherit all of the attributes of TREE, including T. When you create a new instance of WINDOW you must specify T, as in newW :- NEW WINDOW[T, other formal parameters of WINDOW].
alanm@cognos.uucp (Alan Myrvold) (12/22/88)
In article <1826@vlot.cs.vu.nl> jos@cs.vu.nl () writes: >I have some questions about the usage of generic parameters. > >WINDOW inherits class TREE, but it does not specify the generic >parameter of TREE. > >Questions: > > 1. Is this correct Eiffel? (I can't find anything in the book about it) No, the syntax error generated by the compiler is something like: "window", 3: Wrong number of generic parameters for parent class: tree > If we have an object w of type WINDOW, then w.child should be > the same as w.child_value. This looks suspicious, so I think > this is not the right solution. I'm not an eiffel expert (yet) but .... In eiffel, specialization can be done via inheritance and by parameterizing generic classes. You may want to re-read sections 19.3 and 19.4 in Meyer's book. 19.3 Simulating inheritance with genericity. 19.4 Simulating genericity with inheritance. In the windows example, we want "a window IS A tree", so if there was a non-parameterized version of tree we could inherit it and do our work. Alternatively, we could have, say an object called "screen" (which may contain a tree of windows) become a client of a parameterized version of tree. Now "a window IS NOT A tree", but each tree node points to a window. Inheriting AND parameterizing is overkill, which is why w.child is the same as w.child_value. It is not incorrect. Some times we will want the "IS A" relationship with a tree, and other times we will simply want to become a client of tree. So yet another example in eiffel where we are forced to ask ourselves: "Do we buy or inherit?" --- Alan Myrvold 3755 Riverside Dr. uunet!mitel!sce!cognos!alanm Cognos Incorporated P.O. Box 9707 alanm@cognos.uucp (613) 738-1440 x5530 Ottawa, Ontario CANADA K1G 3N3
bertrand@hub.ucsb.edu (Bertrand Meyer) (12/22/88)
In article <65745UH2@PSUVM>, UH2@PSUVM.BITNET (Lee Sailer) writes: > (Quotation from previous message having to do with generic parameters) > > I dunno Eiffel, but this looks enough like Simula that I'll give you > the Simula answer 8-) > > In your example, the WINDOW class *does* inherit all of the > attributes of TREE, including T. When you create a new instance of > WINDOW you must specify T, as in > > newW :- NEW WINDOW[T, other formal parameters of WINDOW]. It may look like Simula but it isn't Simula. T is not an attribute of TREE (the Eiffel term would be ``feature'') but stands for a type, to be supplied in a declaration of an entity (variable) of type TREE [something], e.g. TREE [INTEGER], TREE [WINDOW]. This concept of generic type parameter to a class has no equivalent in Simula. Its presence in Eiffel is what makes compile-time type checking possible (as opposed to the run-time checking required in Simula and most other O-O languages; the only significant exception I am aware of is Trellis-Owl). The class parameters of Simula have a different role: they represent values to be supplied to an *instance* of the class at *run-time* (not parameters to declare a variable at compile-time). The equivalent in Eiffel is provided by arguments to the initialization procedure of the class (called Create). Bertrand Meyer bertrand@eiffel.com
jax@well.UUCP (Jack J. Woehr) (12/26/88)
I guess eiffel is an object-oriented programming environment.
Sounds neato, and also possibly keen &| groovy.
Does eiffel exist on the Amiga yet? asks an Amiga owner, glancing
over his collection of Lisps, Prologs, Forths, C's, Basics ...
{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}
{} {}
{} jax@well ." Sysop, Realtime Control and Forth Board" FIG {}
{} jax@chariot ." (303) 278-0364 300/1200 8-n-1 24 hrs." Chapter {}
{} JAX on GEnie ." Tell them JAX sent you!" Coordinator {}
{} {}
{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}bertrand@hub.ucsb.edu (Bertrand Meyer) (01/12/89)
In article <10122@well.UUCP>, jax@well.UUCP (Jack J. Woehr) writes: > > Does eiffel exist on the Amiga yet? No, although there has been some talk of porting it (nothing done so far). Are people developing ``real'' software on the Amiga? (No offense meant; just asking.) Bertrand Meyer bertrand@eiffel.com
aleks@well.UUCP (Brian J. Witt) (01/16/89)
In article <1098@hub.ucsb.edu> bertrand@hub.ucsb.edu (Bertrand Meyer) writes: >In article <10122@well.UUCP>, jax@well.UUCP (Jack J. Woehr) writes: >> >> Does eiffel exist on the Amiga yet? > >No, although there has been some talk of porting it (nothing done so >far). Are people developing ``real'' software on the Amiga? >(No offense meant; just asking.) > >Bertrand Meyer >bertrand@eiffel.com There is some wild desktop presentation going on... Dale Luck has ported X11 over to the Amiga; black and white only right now. It runs using an Ethernet card attached to the Amiga 500, 1000, or 2000. I saw a demo with an Amiga 500 and 2000 netted to a Sun 2. Everyone was running programs one place with display somewhere else. The Xwindows `kernel' requires about 300K; fonts are extra. Dale wrote the graphics and layering libraries on the Amiga, and is now a contract worker for Amiga-Commodore (as Dave Lucas would say). His siganture is: > -- > Dale Luck GfxBase/Boing, Inc. > {uunet!cbmvax|pyramid}!amiga!boing!dale > There is also a Unix Sys V.3 available for the Amiga. It is a serious start. I'd buy a copy of Eiffel. --- what if, in the media, women weren't exploited? --- brian witt