Re: Real OO

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

Norman wrote:

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

That's okay. I'm a slow learner too :-).
:
:|> 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.

The HOW is specified in Eiffel in two ways:

  i)  Selective export not only says WHO but WHAT (attributes/operations).
      The combination of the two reflects the privileges offered by an 
      abstraction to it's partner/client.
  ii) Executable preconditions. (My guess is that these were omitted from 
      Ada 95 because it would be difficult or messy to control the state of 
      individual abstractions because they are co-encapsulated (It's hard
      enough finding them, let alone controlling them!). The other alternative 
      would be to assert at the package level but that would be a complete joke).

Example:

  class A
    feature           -- anyone may use f1
      f1
    feature {B, C}    -- Only instances of partners B and C may use f2
      f2
    feature {A}       -- All instances of A may use f3 (including Current)
      f3
    feature {NONE}    -- Only the current instance of A may use f4 (secret)
      f4.
  end

:Don is suggesting that some modules can be better trusted than
:others to use certain services correctly.

Only because they are designed to co-operate with each other. It would be 
inaccurate to think of this protection only from the perspective of the supplier.
For the client, selective export gives them the reassurance that they can't
inadvertently misuse the supplier's features. There is no such reassurance for
co-encapsulated abstractions. (I wish someone would give me a dollar for every
time I had to fix a bug caused by one component of an Ada package misusing
another!)

:But such modules should not be
:called clients, they should be called partners.

They are partners and also clients. That relationship may be asymmetical in 
cases (eg. the CELL/LIST example) in which CELL exports to LIST and not vice 
versa.  

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

Expressing trust, yes, but in specific ways so that the privileges are not
carte blanche.

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

There is an enormous 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.

That trust is misguided because it is unrestricted.

:The issue of scale is important here.

IMO, OO principles are equally relevant at all levels of abstraction. Why? 
Because the essence of OO is (contolled) reuse.

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

I don't think anyone said it was.

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

The boundary between the partner abstractions is not a barrier and acknowledging
it's existence only serves to enhance reliability and reusability.

:  Ada
:allows the barriers to be dispensed with at the programmer's discretion;

You sound like a C programmer.

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

Well, gee. And I thought complexity was a bad thing :-).

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

I hope no-one would disagree that formal legal contracts between divisions of
the same corporation are indicative of an apalling corporate culture and that
a co-operative relationship between divisions is a good thing. However, it 
is important to realise that the key to effective operation is a suitable
balance between access to each other's resources and the discipline of how
those resources are made available. A manager of one division cannot just 
march into another and relegate staff from that division without first getting
the approval of that division's manager. Otherwise, the organisation would be 
hopelessly inefficient and collapse due to anarchy. (Perhaps this has some
bearing on IBM's fall from grace :-). However, there are promising signs that 
it is improving).

No, control is still needed, but only as much as required.

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

Don.