🚀 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