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,5394d9ca5f955366 X-Google-Attributes: gid103376,public From: Matthew Heaney Subject: Re: pointers & OOP Date: 1999/05/14 Message-ID: #1/1 X-Deja-AN: 477694749 References: <$DL10CAsSgL3Iwj3@jr-and-assoc.demon.co.uk> <7gn7gr$fr5$1@nnrp1.dejanews.com> <7gq27t$vnd$1@nnrp1.deja.com> NNTP-Posting-Date: Thu, 13 May 1999 22:17:01 PDT Newsgroups: comp.lang.ada Date: 1999-05-14T00:00:00+00:00 List-Id: John Robinson writes: >>Very often putting multiple types into a single package solves in a >>neat and clean way nasty problems that simply don't have neat solutions >>in other languages. > > Such as? Here's one reason: giving types mutual access to each other's representation. It's like a "friend" in C++. Sometimes, two types are just highly cohesive, and you never use one with also using the other. A classic example is a data structure and its (active) iterator. > The use (in general) of one "major" type per package goes back to my > earliest days with Ada 83, and is of course inherent in Booch's > original "Software Engineering with Ada" text which was so influential > in the adoption of ADT-based programming in the Ada world. But if Booch had provided active iterators, then he would have declared them together in the same package. > This approach, which I have (so far) successfully carried over into > Object Oriented Ada 95 code, brings a number of benefits > (e.g. straightforward traceability between analysis and code, very > clear separation of concerns etc). No one is arguing that you put just any types together in the same package. We all agree that that is a bad thing (because it causes unnecessary compilation dependencies). > However, I am open to other approaches, if the benefits are clear. It's called a "package" for a reason -- because it holds in one place all the entities associated with an abstraction. Be careful not to confuse a module with a type. In Ada, an abstraction is provided by a package (or hierarchy of packages). That one or more types are used to implement the abstraction, well, that's just a feature of the implementation. It's the package (really, objects) that's the important thing. That's why when you trace analysis or design artifacts to code, you should really be tracing them to packages with state, not types. It's objects that are important -- types (even ADTs) are mere implementation details. You can (and should) implement abstractions using a package only, without using any abstract data types. This is how you implement well-known objects, a static abstraction whose cardinality is known up front. A singleton is the limiting case of a well-known object whose cardinality is one. The package Ada.Text_IO is a good example of an abstraction that contains multiple types and static state. The abstraction is "text i/o", not just "file type". Package Text_IO contains these types: File_Type Count Positive_Count File_Mode and at least three local variables: Standard_Input Standard_Output Standard_Error See my articles about singletons/well-known objects in the Feb 97 and Jun 98 archives. > >You are tieing BOTH hands behind your back if you adopt this completely > >unnecessary and damaging restriction. > > I would be very interested in seeing a specific example of why this is > damaging. Perhaps a specific reference to the patterns archive cited > by Matthew? Study the article Iterator and Factory Methods Combined, in the Nov 98 ACM patterns archive. In that example a stack has a factory method that returns an iterator. See also the examples and discussions of the Observer pattern, in the March 99 archive. For example, here's the spec: package Subjects_And_Observers is type Root_Subject_Type is abstract tagged limited private; procedure Notify (Subject : in out Root_Subject_Type'Class); type Root_Observer_Type (Subject : access Root_Subject_Type'Class) is abstract tagged limited private; procedure Update (Observer : access Root_Observer_Type) is abstract; ... end Subjects_And_Observers; One abstraction, one package, two types. As I explained to Ed Falis (on Mar 19, 1998): (start of excerpt) > Ed Falis writes: > Third, I just plain dislike placing the field for linking onto the observers > list into the observer. This is more an aesthetic issue than anything else, > but it makes implementation of the observer list just a little too visible > for my taste. I take the attitude that when you have mutually dependent types, together in the same package, that the types must be treated as a unit. The subject and observer types are highly cohesive parts of a larger abstraction ("publish subscribe"), and you can't study them independently of each other. (end of excerpt) Matt