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: 103376,df854b5838c3e14 X-Google-Attributes: gid103376,public From: donh@syd.csa.com.au (Don Harrison) Subject: Large Scale OO Development (was Re: C/C++ knocks the ....) Date: 1996/02/22 Message-ID: X-Deja-AN: 140575853 sender: news@assip.csasyd.oz references: organization: CSC Australia reply-to: donh@syd.csa.com.au newsgroups: comp.lang.ada Date: 1996-02-22T00:00:00+00:00 List-Id: Tucker Taft wrote: :Matt Kennel (kennel@msr.epm.ornl.gov) wrote: :: ... :: As for Ada, I'm not yet fully convinced abou the package vs :: type thing. C++ might be ugly because you can have all sorts of :: elements outside classes, but in Eiffel you cannot. : :: Eiffel intentionally makes the unit of namespace and of type :: the same. : :: The question is, do the benefits of having them completely separate :: make up for the extra work and complexity of having to double the :: number of 'mental units' in most idiomatic programs. (and without :: MI you have to go a bit further) : :: Yes, Ada has them on orthogonal axes. Eiffel only has "one axis" :: but it may empirically be along the major princpal component with :: only a small deviation in other directions. : :On the other hand, various Eiffel implementations have felt the :need to add yet another language on top for doing "configuration" :of large systems (I think it is called "GRACE"?). Eiffel (as you would be aware) has been purposefully designed as a 'minimalist' OO language. In this approach, the minimum required mechanisms are included in the language proper but where possible, functionality is defined in standard library classes and by reusing them to define other standard classes. To preserve the purity (generality) of code, configuration information and compiler directives are segregated into the ACE (Assembly of Classes in Eiffel) file. The contents are described in LACE (Language for ...) which follows an Eiffel-like syntax. So, the real definition of the language is the core language + standard classes + LACE. Since each is simple to comprehend (and the core language and LACE are similar), it takes very little effort to get a handle on Eiffel. The advantages of this approach are several: 1) The core language is kept as simple as possible meaning that it is easy to learn and there are few concepts that the developer must grasp leaving him free to channel mental energy into abstractions. 2) The language definition itself employs reuse (both of classes and mechanisms). 3) Software text is not cluttered with information not inherent to the abstractions but specifying how the program is executed (eg. configuration information, compiler directives etc.). This approach contrasts with that of Ada in which the core language is comparitively complex because most functionality has been included in the core language. (The use of Annexes in Ada 95 is a step in the right direction but it's like shutting the gate after the horse has bolted. Note that the complexity of Ada means that the developer has to devote excessive mental energy to language details which ought to be applied to creating suitable abstractions. Minimalist languages win hands down on this score. : This seems :to indicate that programmers have a need to deal with larger groupings :than that represented by a single class. Although one could conceivably :just create larger and larger classes, at some point the model of a "type" :breaks down, whereas the notion of a package scales nicely to the :notion of a subsystem, as in Ada 95. Why should the encapsulation solely via classes break down for large systems? I don't see why you can't (with well designed frameworks of classes) continue reusing classes ad nauseum. Encapsulation using classes should cause no greater impediment to creating higher level abstractions than encapsulation using packages. If anyone can convince me otherwise, I'm happy to be educated. :It is interesting to note that Java has the notion :of "package" for defining groups of classes. This seems :like a reasonable compromise, though it still loses out on some of the :other advantages of defining abstractions using a package rather than a :class, such as symmetry of parameters in binary operations, and elimination :of the pesky "once" or "static" qualifiers of Eiffel/C++/Java that are :needed to turn a "component" of a type into a component of a module. Attributes are not changed from being components of types to components of modules through the use of 'once' functions. They are already components of modules because the type IS the module. Their status is simply changed from being unique to each instance to being shared by all instances (class attributes rather than instance attributes). I'm not aware of any difficulties with this approach, so 'pesky' may not be an appropriate epithet :-). :-Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ :Intermetrics, Inc. Cambridge, MA USA Don.