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,836e43045b715f57 X-Google-Attributes: gid103376,public From: Mark Lundquist Subject: Re: Package reformatting tool availability Date: 1999/09/14 Message-ID: <37DEDCF1.946A6AD0@rational.com>#1/1 X-Deja-AN: 525191821 Content-Transfer-Encoding: 7bit References: <37CFFA58.FFC67480@res.raytheon.com> <7qpeg1$2di$1@nnrp1.deja.com> <37D542F9.3C6C9F4D@res.raytheon.com> <7ree14$t3h@dfw-ixnews6.ix.netcom.com> Organization: Rational Software Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-09-14T00:00:00+00:00 List-Id: Richard D Riehle wrote: > In article <37D542F9.3C6C9F4D@res.raytheon.com>, > Andy Askey wrote: > > >a different criteria for grouping types within packages. It appears > >that there is some rule of thumb that only about 30-50 types can be > >placed in one package. When more types are created, there is an obvious > >need for another package. > > One of the problems with the Ada package is how it encourages such > practices. I wouldn't agree that Ada "encourages" this. Ada allows it. So does C++. You can define any number of classes is in a file, as many as you like (similarly, a Java package can contain arbitrary class definitions). While packages may seem to contain primitives in the same sense that classes contain member functions, the C++ analogue of a package is not a class. If anything, the (poor) C++ analogue of an Ada package is the "file", as in ("header file" and "implementation file"). There is another aspect in which the analogue of the Ada package is the C++ namespace. > This reflects one of the benefits of C++ or Eiffel: each > C++ class is a type. That's more of a definition than a statement, so I'm not getting what the benefits are... > If I still understand object-oriented modeling, a > package should export one main type with appropriate operations on that > type. The structure of the type is hidden from a client of the package. > The package may also export some supplementary types such as enumeration > types, etc. > > Does this create too many packages? What is too many? Robert Dewar > is fond of reminding us that Ada is designed to be more readable than > writeable. That is one of goals of encapsulation and information hiding, > isn't it? Actually, I would say not. The goals of encapsulation have to do with abstraction (and whether abstraction leads to greater readability is sort of in the eye of the beholder, and it involves lifecycle considerations too). Readability is the goal of clean syntax. > I thought Brad Balfour and Ed Seidiwitz long ago put the issue > of global Ada type packages to rest. > > Also, with the advent of generic formal package parameters, child library > units, private child units, and the new renaming options, Ada 95 makes > it easy to design small packages that support the behavior of one type > In fact, used correctly, these features of Ada 95 put Ada ahead of some > other languages such as C++ where type <=> module <=> class. > I'd say Ada95 is ahead even without considering those features, but...:-) Are you saying that Ada's separation of typing and modularity is a weakness (as you seemed to be saying earlier), but that this weakness is overcome by the correct use of certain other features? I believe that the conflation of type and module into one construct is a mistake -- unfortunately, that's the "idea package" in which most of us (myself included) first encountered OO, thanks to Alan Kay and Adele Goldberg. At the time, this idea was a great experiment (not the only great experiment of the Smalltalk environment, of course -- the other was the window-mouse MMI paradigm). And paradoxically, it was necessary that OO hit the streets in the radicalized, class-oriented form, because the computing community really did need to have its collective brain washed in order to understand and accept the value of the underlying, true OO concepts (encapsulation, inheritance, polymorphism, and for all but the most extreme "purist", genericity). But the attempt to fundamentally define and forumulate OO in terms of the class construct is moribund. I've been wanting to write an article about the myth of "pure OO" and the brokenness of class-centered OO... just haven't been able to make the time to do it. Plus, I don't know if the world is ready... :-) :-) -- Mark Lundquist Senior Software Engineer Rational Software Development Solutions Business Unit UNIX Suites Group Aloha, OR, USA