From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,c52c30d32b866eae X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,2ea02452876a15e1 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,c52c30d32b866eae X-Google-Attributes: gid1108a1,public From: ncohen@watson.ibm.com (Norman H. Cohen) Subject: Re: Real OO Date: 1996/03/26 Message-ID: <4j9s1c$uo5@watnews1.watson.ibm.com> X-Deja-AN: 144391731 distribution: world references: <4iv58e$113p@watnews1.watson.ibm.com> organization: IBM T.J. Watson Research Center reply-to: ncohen@watson.ibm.com newsgroups: comp.lang.ada,comp.lang.eiffel,comp.object Date: 1996-03-26T00:00:00+00:00 List-Id: In article , 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