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,73036d0217be91e2 X-Google-Attributes: gid103376,public From: "John G. Volan" Subject: Re: Inheritance versus Generics Date: 1997/05/02 Message-ID: <336AE16D.2830@sprintmail.com> X-Deja-AN: 239043159 References: <33601924.774@flash.net> <5jql3p$p9p@top.mitre.org> <01bc5272$cbd7d400$28f982c1@xhv46.dial.pipex.com> <5k5suu$bhj@top.mitre.org> Organization: Sprint Internet Passport Reply-To: johnvolan@sprintmail.com Newsgroups: comp.lang.ada Date: 1997-05-02T00:00:00+00:00 List-Id: Michael F Brenner wrote: > Arrays of packages are what is missing in Ada-95 for packages to > act as objects. I must admit that I find this whole discussion of packages as first- or second- class objects somewhat confusing. I don't quite see what they buy you that isn't already supported by tagged record types and generics. Michael, it might be helpful if you could post a "code" example that showed what you had in mind for the syntax and semantics of these beasts. :-) Then either someone could show you that what you want can actually be done in Ada95, or else you could make it clear what is missing. > 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. Sigh ... is this just a religious issue over cosmetics? Why so much bitterness over superficial syntactic differences? Isn't it plain that there's a _semantic_ homomorphism between these two notations: controlling parameter (target) distinguished by type analysis (doesn't necessarily have to be first) | | scope.method (target, parameters); -- Ada95: scope = package | -- "scope." can be omitted | -- after a "use" period as scope delimiter double-colon as scope operator | | target.scope::method (parameters); // C++: scope == class | // "scope::" can be omitted | // anytime controlling parameter (target) distinguished by period syntax Can you not see how parochial your interpretation of the period character (.) is? An analogy: In the United States, we write out numbers thus: "123,456.789". In some countries in Europe, the same number might be written thus: "123.456,789". A telephone number in the US is usually written like this: "(800) 555-1212". The same number might be written in Europe as: "800.555.1212". Does anyone have a problem with this? _I_ sure don't. I can figure out what is meant either way. > BTW, this method of grouping methods with the object not only preceeds > the great object-oriented languages such as smalltalk, Ada-95, and Java, What about Common Lisp? A very object-oriented language indeed, and yet it manages to do this without changing the old Lisp syntax: (method target parameters) ;; controlling parameter doesn't ;; necessarily have to be first > but also predates computer science. For example, category theory, > abstract algebra, and discrete mathematics have all grouped the methods > with the objects, Mathematics groups methods with _objects_? Or does it group methods with _types_? What do you mean by "grouping"? An Ada95 package can declare a type and its associated primitive subprograms together. In fact, that's what defines those subprograms as "primitive" -- their co-location in the same package spec with the type. In what way does this fail to achieve the "grouping" you seek? Why do I suspect that it won't count as "grouping" unless it is attended with the "politicially correct" syntactic sugar? > rather than using a structured programming approach > with a top-down design. What does this have to do with Ada95? Are you somehow insinuating that Ada95 packages cannot support any notion other than top-down structured design? Surely you can't mean that, given the overwhelming evidence to the contrary! > 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. Sounds like sour grapes to me. I do remember seeing something about package types way back when during the Ada9X process. I bet they were discussed seriously and extensively. But, as we all know, a different solution was chosen instead. It is my belief that the current solution can be shown to be _semantically homomorphic_ to whatever it is that you want, but it will take a concrete example to demonstrate that. > 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. Interesting. How would your package-passing concept create "multiple inheritance"? And why do you think multiple inheritance is what you need to solve the kind of problem you describe, anyway? MI is not the only technique for flexibly composing abstractions. Sounds like a case of "hammer syndrome" to me (that's where every problem looks like a nail). > 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. Interesting. It seems to me that something like this _can_ be achieved with tagged types, combined with generics. Let's see this example fleshed out a bit, then we can talk. > 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. Why can't this be achieved using an abstract tagged type with multiple concrete derived types and classwide programming? > 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). Interesting. Again, a fleshed out example might be instructive. > 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. Well, maybe they've _already_ been solved... ------------------------------------------------------------------------ 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? :-) "); ------------------------------------------------------------------------