Re: Real OO

[ncohen@watson.ibm.com (Norman H. Cohen)]

In article <Dov7D0.AtM@assip.csasyd.oz>, donh@syd.csa.com.au (Don Harrison)
writes: 

|> The Eiffel selective export may seem the wrong way of doing it at first sight.
|> You might wonder: 
|>
|>   "What's the supplier class doing dictating who can and can't use it's
|>    features? It exists for the purpose of it's clients, so, if anything,
|>    named subsets of exported features should be provided by a supplier
|>    and clients should be able to choose which subset they need".

Indeed, I do.

|> However, this would be a violation of Design by Contract because it is the
|> supplier class that must control it's own state. Therefore, it must dictate
|> how it's services are used and by whom. If the client were able to able to
|> choose a particular interface, it might be able to choose one which was more
|> permissive than the supplier had intended for it and the door would be open
|> to the client potentially changing the supplier to an inconsistent state.

Selective export cannot control HOW a supplier's services are used, only
by whom.  Don is suggesting that some modules can be better trusted than
others to use certain services correctly.  But such modules should not be
called clients, they should be called partners.  Indeed, Don continues: 

|> The intention of selective export is for classes to make available to 'closely
|> related' classes features that are intended specifically for them.

Now what do we mean by "closely related"?  In part, we mean that one of
the classes is implemented in terms of internal features of the other
(internal at least in the sense that such features are not available to
the general public).  The classes were probably designed in conjunction
with each other, most likely by the same group of designers, as part of a
cooperative system.  By giving its partner access to privileged
operations, a class is expressing trust in that partner.

...
|> :  Nesting multiple type
|> :definitions (suitably hidden) inside a single Ada package accomplishes
|> :the same thing.
|>
|> By no means! The co-encapsulated model destroys the export contract between the
|> related abstractions. What you end up with is a free-for-all for whoever
|> happens to live in the same module. "You want to change my state? Well, step
|> right up and do whatever you like!".

This is a distinction without a difference.  Only parts of the program
that trust each other live in the same module.  In Eiffel, the definer
of type A expresses trust in the definer of type B by selectively
exporting to B the right to use potentially destructive features.  If B
wants to change A's state, it can "step right up" and do so.  In Ada this
trust can be expressed by co-encapsulation--declaring A and B in the same
package.

The issue of scale is important here.  The example in question involved
one type for linked list cells and another type for abstract lists,
consisting of a length and (a reference to) the first linked cell.
The whole package is a few dozen lines, conceived as a single entity.
This is not a toy example.  Along with the complex data abstractions
found in real-world programs are lots and lots of very simple data
abstractions like this one, and they account for a considerable portion
of program text.  For multitype data abstractions like this one,
artificial barriers between the two types just get in the way.  Ada
allows the barriers to be dispensed with at the programmer's discretion;
Eiffel does not.  Ada also allows more intricate program structures,
involving private child packages, that allow parts of a package's
implementation to be separately encapsulated and to provide
features that are hidden from outside clients; however such structures
are not forced upon the programmer in cases where they are overkill.

...
|> :Because of the ability to define more than one type in the same module in
|> :Ada, selective export is of less interest to an Ada programmer than to an
|> :Eiffel programmer.
|>
|> It ought to be, IMO. I suppose, if contracting were treated with the same
|> importance in Ada as it is in Eiffel, they would be just as interested :-).

Actually, Ada is all about contracts, where they are appropriate.  I am
reminded of a talk Lou Gerstner gave shortly after he became CEO of IBM,
in which he expressed his astonishment at the formal legal contracts that
he found being drawn up between different divisions of the same
corporation.  This did not diminish in any way his appreciation of the
importance of contracts with outside parties.

--
Norman H. Cohen    ncohen@watson.ibm.com