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,73036d0217be91e2 X-Google-Attributes: gid103376,public From: mfb@mbunix.mitre.org (Michael F Brenner) Subject: Re: Inheritance versus Generics Date: 1997/04/29 Message-ID: <5k5suu$bhj@top.mitre.org>#1/1 X-Deja-AN: 238368319 References: <33601924.774@flash.net> <5jql3p$p9p@top.mitre.org> <01bc5272$cbd7d400$28f982c1@xhv46.dial.pipex.com> Organization: The MITRE Corporation, Bedford Mass. Newsgroups: comp.lang.ada Date: 1997-04-29T00:00:00+00:00 List-Id: Nick said > Fill me in on arrays of packages Arrays of packages are what is missing in Ada-95 for packages to act as objects. For example, in any generic instantiation which creates an ADO (abstract data object), you can use object oriented notation to access the methods (package.method is identical to object.method in this case. ) However, in the case of an ADT (abstract data type), the package permits you to create a type (class) from which objects are then created. In this case package.method is not equal to object.method; instead, you need to say package.method (object). This partial inversion of the notation (object.method in ADOs versus package.method for ADTs) results in many anomalies, such as most existing generic code being ADOs, to make the objects LOOK like objects. BTW, this method of grouping methods with the object not only preceeds the great object-oriented languages such as smalltalk, Ada-95, and Java, but also predates computer science. For example, category theory, abstract algebra, and discrete mathematics have all grouped the methods with the objects, rather than using a structured programming approach with a top-down design. Mathematicians have followed the best of the object-oriented philosophy (design bottom up, relating the methods to the objecs) but describe that design top down in a logical manner. Making arrays of objects AS Packages would make packages into what is called First Class Objects. This is not politically feasible given the beliefs of the people who get to vote on this. However, making the packages second class objects, that is permitting passing of packages (non-generic) to packages adds no new problems; it only suffers from the same things that any other form of multiple inheritance suffers from. For example, if we have a double linked list package and a scheduling package and a 3d transformation package, there are severe limitations to our ability to make linked lists of scheduled transformation. We basically have to create each level of intermediate object MANUALLY, inducing the comcomitant bugs, and imbuing the source code with lines of code which packages as second class objects would obviate. When you have existing packages and you know how you would like to parameterize them, it would be nice if Ada-2005 would permit you to do it. The type of problem we are trying to solve in this discussion is the classical case of multiple back ends for a single visible part. With external file systems and configuration management tools, we can have multiple back ends. However, within the Ada language, we can only do this if we have a single level of inheritance (or if we manually create the intermediate record types which, as said above, is error-prone). If packages were second class objects (passable to packages), then we could re-instantiate new back ends for packates within the language. While not as cool as arrays of packages, it would solve the outstanding issue of programming for multiple backends within the Ada-2005 language. It would NOT require the creation of packages as TYPES, but rather would re-use the concept of abstract packages, and merely relieve the restriction that packages as parameters must be generic. There are problems, yes, and those problems are worth solving, yes. .