🚀 go-pugleaf

(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

Would someone please give me a brief introduction to Eiffel and the
availability of the compilers?

Thank you.


-------------
Francis Kam                           CSC-3475
Internet: mkkam@cs.uh.edu             Computer Science Department
(ARPA)    mkkam@sun1.cs.uh.edu        University of Houston
CSNET:    mkkam@houston.csnet         4800 Calhoun
Phone: (713)749-1748                  Houston, TX 77004,
       (713)749-4791				  USA

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].

I'm sure a brief introduction would be welcome to all the readers of this
newsgroup who are reading out of pure curiosity (Who knows, we might become
interested enough to contribute. 8').

--
Mark Charette             "People only like me when I'm dumb!", he said.
Electronic Data Systems   "I like you a lot." was the reply.
750 Tower Drive           Voice: (313)265-7006        FAX: (313)265-5770
Troy, MI 48007-7019       charette@edsews.eds.com     uunet!edsews!charette

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

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

	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 {}
{}									  {}
{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}

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

What systems is eiffel available for?


Mike Walker  :-]
arpa: walker@oberon.usc.edu
uucp: uunet!oberon!walker

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

Is there any mechanism to allow universities to conduct ports of
eiffel to new environments (e.g. IBM AIX (3090), Xenix (PS2),
MACH (neXt)...). I will be teaching software engineering in these
system environments in coming semesters and would really like to
use eiffel for academic and research activities.

From <637@usl.usl.edu>, drm@usl.usl.edu (Dennis Moreau):
>
> Is there any mechanism to allow universities to conduct ports of
> eiffel to new environments (e.g. IBM AIX (3090), Xenix (PS2),
> MACH (neXt)...). I will be teaching software engineering in these
> system environments in coming semesters and would really like to
> use eiffel for academic and research activities.

We support AIX and Xenix directly so there is no need for a specific port.
For NeXT (I hope I got the upper-case letters right) nothing has been done
so far. (The interest of porting Eiffel there was mentioned by an earlier
contributor to this newsgroup.)

For environments that we do not (or do not yet) directly support,
arrangements can be made to have a customer, industrial or academic,
do the port. We require a serious guarantee of non-disclosure
and the provision that we will receive a copy of the result of the
port. This arrangement has been used a number of times to make
Eiffel available to users having machines that are somewhat off
the beaten track. As long as the target is a reasonable Unix, the
technical work involved is not hard.


-- Bertrand Meyer
Interactive Software Engineering
bertrand@eiffel.com