Re: Real OO

[donh@syd.csa.com.au (Don Harrison)]

Norman H. Cohen wrote:

:When Don Harrison asked how to achieve selective export in Ada, I
:proposed a technique, but I never asked why one would want selective
:export.
:
:Selective export does indeed help document the modular structure of a
:program, and make the program easier for a reader to understand, but it
:seems to me that the documentation is in the wrong place.  In general,
:the writer of a program component should be as unaware as possible of the
:context in which that component will be used, especially if loose
:coupling and reusability are valued.

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

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.

The intention of selective export is for classes to make available to 'closely
related' classes features that are intended specifically for them. When the 
features are selectively exported to the same class, it means they are available 
to other instances of the same class and when they are exported to NONE, they
are 'secret', like attributes and operations in an Ada package body.
When features are not specifically designed for a particular class, they should
be generally exported (by omitting the export clause) which, as you would expect,
is the default. This acheives the loose coupling and reusability which you
correctly identify should be the norm.

:I don't find Bertrand Meyer's example of selective export in
:_Object-Oriented_Software_Construction_ particularly compelling.  That
:example would be written in Ada as follows: 
:
:   generic
:      type Element_Type is private;
:   package Lists is
:      type List_Type is private;
:      ...
:   private
:      type Cell_Type;
:      type Cell_Pointer_Type is access Cell_Type;
:      type Cell_Type is
:         record
:            Data : Element_Type;
:            Link : Cell_Pointer_Type;
:         end record;
:      type List_Type is
:         record
:            Length : Natural;
:            Cells  : Cell_Pointer_Type;
:         end record;
:   end Lists;
:
:However, because of the Eiffel constraint that module = class = type,
:Meyer cannot define List_Type in the same class as Cell_Type.

Nor does he wish to :-).

:  Therefore,
:he puts his equivalent of Cell_Type in a separate class which is
:selectively exported only to the List_Type class.

a la:

class CELL [ELEMENT_TYPE]
  feature {LIST}
    data : ELEMENT_TYPE
    link : CELL
  ...
end

class LIST [ELEMENT_TYPE]
  feature
    length : INTEGER
    cells  : CELL
  ...
end

:  (There is no need for
:an explicit Cell_Pointer_Type in Eiffel because of Eiffel's implicit
:reference semantics; the Link component belongs to Cell_Type.)

Great idea!

:Perhaps Don will decry this as "quasi-encapsulation", but the whole point
:of the selective export in Eiffel was to emphasize that the Eiffel class
:corresponding to Cell_Pointer_Type was to be used only in the module
:defining the Eiffel analog of List_Type.

No, I wouldn't because they are distinct abstractions (albeit closely related 
ones).

:  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!". Likewise, you are forced to provide
a one-size-fits-all export contract to clients outside the module, which, as 
argued above, can also result in the abstractions being changed to inconsistent
states. Basically, export contracts get shot to pieces or don't exist at all
(internally) if co-encapsulation is used. The alternative is the not-so-beautiful
quasi-encasulated paradigm already discussed.

The Eiffel approach allow more control, more elegantly, IMO.

: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 :-).

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