So called Real OO (was blah blah blah...)

[jsa@organon.com (Jon S Anthony)]

In article <Dn9BzB.IMA@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

> You seemed to object strongly to the idea that one can put two types in
> the same package, on the grounds that it decreases encapsulation.  On
> the contrary, it *increases* encapsulation.  When two types are closely
> related to each other, by their nature, *forcing* them to be in separate
> modules means that *more* operations need to be exported from each
> module.

Yes, but in this context (Eiffel) it is mostly irrelevant.  This is
because the two classes can export the "detail stuff" to each other
_only_.  This is from selective export, in particular the optional
part of a feature clause (listing its client classes).  See ETL 7.12
and 7.13.

> mentioned above, about putting list-cursor information inside the list
> itself?  If you have multiple tasks, you definitely want to have two
> tasks iterating through the same shared list (or whatever data
> structure).  Has the standard class library been changed to solve this
> problem?

I think you are confused here.  Iteration is effected by inheriting
from say, list_iteration, when defining some class that needs to be
"iterated over".  In effect, list_iteration supplies only the pattern,
so the particular class has the "cursor" (which is not accessible in
any event).  To handle more than one iteration, you repeatedly inherit
list_iteration (renaming bits as appropriate).  Now, the real problem
here (as has been discussed to death on c.l.e) is that the repeated
inheritance machinery exists in the main to support this iteration
aspect and it is rather complicated and subtle machinery to handle
such a simple thing.  In some respects this bit is the Eiffel
counterpart "dirty laudry" to the "mutual withing" problem in Ada:
Yes, you can get the thing to work, but it isn't pretty.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com