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.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,baa6871d466e5af9 X-Google-Attributes: gid103376,public From: "John G. Volan" Subject: Booch "forms" and child packages [was: AQ&S Guidance on pragma Elaborate_Body] Date: 1997/05/02 Message-ID: <336A14E2.70B6@sprintmail.com>#1/1 X-Deja-AN: 238937833 References: <528878564wnr@diphi.demon.co.uk> <5jabeq$3ltk@info4.rus.uni-stuttgart.de> <5jfukp$lda@top.mitre.org> <33660F4B.1B45@sprintmail.com> <33698E5C.22AA@sprintmail.com> Reply-To: johnvolan@sprintmail.com Newsgroups: comp.lang.ada Date: 1997-05-02T00:00:00+00:00 List-Id: Apologies for following up my own post, but I had a thought: John G. Volan wrote: > > This suggests that iterators might be better off in a _child_ package. > The iterator type could still see the implementation details of the > stack type, but the original stack package wouldn't be "cluttered" with > this extra concept of an iterator. This way, iterators are optional: If > an application needs them, it can "with" the child package; if it > doesn't need them, it won't have to pay the cost of having the iterator > code linked in. One of the problems I had with the old Booch components was how Booch's notion of "forms" introduced so much duplication of code into his ADT library. For instance, one dimension of form Booch considered was whether an ADT package included support for iterators or not. For every package that did provided iterators, there would be another one that didn't. Often times both packages would be identical except for the iterator stuff. This must present something of a configuration nightmare if you're the maintainer of the ADT library. Multiply this by all the various "form" dimensions Booch identified, and you get a combinatorial explosion of slightly different versions. I can see why Booch had to do this: Features such as iterators are really optional, so clients ought to be allowed to select whether they want all that baggage included into their applications or not. In Ada83, with its flat library space, the only recourse was to have duplicate packages providing slightly different versions of the same ADT. In Ada95, you can avoid this problem (in some cases) by exploiting Ada95's hierarchical library space: For instance, as I described above, you can write a base ADT package without iterators, and then support the iterator concept in a child package. The iterator child package doesn't duplicate any code from the parent ADT package, it just adds whatever extra is needed to support this extra concept (and can exploit knowledge of the private implementation details of the ADT in order to do so). Yet this arrangement still gives clients all the flexibility they need: If they only need the base ADT, that's all they need to "with"; if they also need iterators, they can "with" the child package, too. ------------------------------------------------------------------------ Internet.Usenet.Put_Signature (Name => "John G. Volan", Home_Email => "johnvolan@sprintmail.com", Slogan => "Ada95: The World's *FIRST* International-Standard OOPL", Disclaimer => "These opinions were never defined, so using them " & "would be erroneous...or is that just nondeterministic now? :-) "); ------------------------------------------------------------------------