Re: Real OO (was Choice of OO primitives in Ada95)

[croizier@rennes.enst-bretagne.fr (Valery Croizier)]

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.
> [...]
> An example is a List type, plus a List_Cursor type.  The List_Cursor
> points at a certain place in the list, and has operations for moving
> forward and/or backward and so forth.  These operations cannot be
> written without visibility on implementation details of *both* types.
> So if class=module, you have to *export* a lot of those implemenation
> details from one of them, so the other one can do what it needs to do.
> Putting them both in the same module, however, actually gives you
> *better* encapsulation, because fewer (and higher-level) operations get
> exported.

Yes, you have to export internals to the other class, but
encapsulation is not weaker, because you can do a selective export, so
that no one (except List_Cursor) can see List's internals.
Putting two types in the same module weakens encapsulation, because it
exports : 
	o *all* internals 
	o to *each other* types 
in that module, while Eiffel allowes the programmer to export only
useful data to classes that need them.
For example, type Person has a field Disease.  Only a Doctor can see
this field, because only doctors are able to identify diseases.
You can't put Person and Doctor in the same package, because :
	o Doctor would see *all* private data of Person
and, that is worse,
	o Person would see all private data of *Doctor*.
Ada's solution works fine with the List_Iterator issue, because
List and List_Cursor aren't complex structures.

> [...]
> So I've heard.  How does this new elegant model deal with the issue I
> 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?

The issue have little to do with tasking. Even in a sequential
program, a List can have several clients.
As far as Eiffel Libraries are concerned, I don't know them well, but
I've just ckecked ISE's and Tower's Web site, and there is no list in
the Library Kernel.  Of course, vendors provide their own librairies,
and the most prominent ones have traversable lists (at least Sig and
Tower have).

--
Valery CROIZIER