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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2ea02452876a15e1 X-Google-Attributes: gid103376,public From: croizier@rennes.enst-bretagne.fr (Valery Croizier) Subject: Re: Real OO (was Choice of OO primitives in Ada95) Date: 1996/02/24 Message-ID: #1/1 X-Deja-AN: 140966240 distribution: world sender: croizier@lupin.rennes.enst-bretagne.fr references: content-type: text/plain; charset=US-ASCII organization: ENST de Bretagne, Rennes, France mime-version: 1.0 newsgroups: comp.lang.ada Date: 1996-02-24T00:00:00+00:00 List-Id: In article 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