Inheritance versus Generics

Inheritance versus Generics

[Craig Smith]

Generics were a very power feature of Ada-83.  With the OO features
introduced into Ada-95 (in particuliar, the tagged record and ability to
inherit), are Generics obsolute?  I would guess since several features
were added to generics (like generic formal package parameters), the
answer is no.  Does anyone have any thoughts on this?

Craig D. Smith

Re: Inheritance versus Generics

[Robert A Duff]

In article <33601924.774@flash.net>, Craig Smith  <cdsmith0@flash.net> wrote:
>Generics were a very power feature of Ada-83.  With the OO features
>introduced into Ada-95 (in particuliar, the tagged record and ability to
>inherit), are Generics obsolute?

No, generics are not obsolete.  Bertrand Meyer explains why quite
clearly in his OO book.  He talks a lot about Eiffel, but his arguments
on this point apply to Ada as well.

*Some* uses of Ada 83 generics are better done with Ada 95 tagged types,
but certainly not all.  In fact, a mixture of the two features often
makes sense.  E.g., consider data structure generic package, like
"Generic_Lists", where the element type is a generic formal parameter.
You might want to have homogeneous lists of some specific type
(list-of-integer).  You might also want to have heterogeneous lists, by
passing in Some_Type'Class.  The same generic works for both.

If you use tagged types to make your lists, instead of generics, then
you end up losing type checking -- you *can't* constrain the type of
list elements.  (Java has this problem, as does Smalltalk.)  You also
end up having to derive from some central List_Item type, so if you have
an existing type T, you have to go back and modify if it you want it in
lists.  (Assuming the links are in the list items, which is one way you
might want to do it.)  (Smalltalk doesn't have this problem.  But then
it doesn't try to do much type checking.)

>...  I would guess since several features
>were added to generics (like generic formal package parameters), the
>answer is no.  Does anyone have any thoughts on this?

And generic formal derived types.

- Bob

Re: Inheritance versus Generics

[Tucker Taft]

Craig Smith (cdsmith0@flash.net) wrote:

: Generics were a very power feature of Ada-83.  With the OO features
: introduced into Ada-95 (in particuliar, the tagged record and ability to
: inherit), are Generics obsolute?  I would guess since several features
: were added to generics (like generic formal package parameters), the
: answer is no.  Does anyone have any thoughts on this?

This one should get a lot of responses...

Inheritance is good for building an extensible abstraction,
whereas a generic is good for building a parameterized abstraction.

The distinction between extension and parameterization is fundamental
in my view, and both are very useful.

It is interesting to look at Java, which supports only extension --
no parameterization.  You can't build a compile-time-type-safe container 
abstraction in Java, such as a list of T, or a dictionary mapping
T1 to T2, without writing a separate one for each possible T, or each
possible T1/T2 combination.  In Java, you end up using the univeral
"java.lang.Object" class for many things, allowing you to create
heterogenous "bags" of anything, but similarly providing no compile-time
guarantee that a given "bag" has only what you want in it.

By the way, our Ada 95 => Java byte code compiler supports both
generics and extension, since generics are basically a compile-time
concept, and we are only using the Java run-time model, not its
compile-time model.  I might say, when I am feeling a bit unfair, 
that Java has an elegant run-time model dressed in an impoverished 
surface syntax.

: Craig D. Smith

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

Re: Inheritance versus Generics

[Mats Weber]

Craig Smith wrote:
> 
> Generics were a very power feature of Ada-83.  With the OO features
> introduced into Ada-95 (in particuliar, the tagged record and ability to
> inherit), are Generics obsolute?  I would guess since several features
> were added to generics (like generic formal package parameters), the
> answer is no.  Does anyone have any thoughts on this?

No, generics are by no means obsolete. The were also introduced into
Modula-3, which already had inheritance, by people who like simple
languages.

You can simulate generics with inheritance (the technique is described
in Meyer's "Object Oriented Software Construction" (very good book
BTW)), but it is really just a simulation, not the real thing. You loose
type checking among other things. Note that Eiffel also has generics.

Re: Inheritance versus Generics

[Matthew Heaney]

In article <3360CA7A.2272@elca-matrix.ch>, Mats.Weber@elca-matrix.ch wrote:

>You can simulate generics with inheritance (the technique is described
>in Meyer's "Object Oriented Software Construction" (very good book
>BTW))...

A very good book that every programmer should read.  The 2nd edition has
just come out, with some egregious cricisms of Ada.  And I was naive enough
to hope that once type extension and dynamic dispatching were added,
Bertrand would like Ada.  Comments, anyone?

Matt

P.S. He actually has a link to your dissertation in his book, Mats.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Inheritance versus Generics

[Robert Dewar]

Matthew Heaney said

<<A very good book that every programmer should read.  The 2nd edition has
just come out, with some egregious cricisms of Ada.  And I was naive enough
to hope that once type extension and dynamic dispatching were added,
Bertrand would like Ada.  Comments, anyone?>>

Well the world of language advocacy has always been one in which people
are very ready to criticize without much practical experience. A good rule
would be that you should not criticize a language unless you have written
substantial amounts of real delivered production code in that language.

That would eliminate Bertrand's criticisms, it would also eliminate a lot
of the criticisims on CLA of other languages.

Come to think of it, it might pretty much eliminate all language advocacy
altogether :-)

Re: Inheritance versus Generics

[Bertrand Meyer]

Robert Dewar wrote (apropos my book "Object-Oriented Software
Construction", second edition, Prentice Hall, and some of its
critical comments about Ada 95):

> Well the world of language advocacy has always been one in which people
> are very ready to criticize without much practical experience. A good rule
> would be that you should not criticize a language unless you have written
> substantial amounts of real delivered production code in that language.

A bit facile perhaps. Prove that my comments about Ada 95 are wrong,
if they are; or, barring such a proof, state where and why you
disagree; but discuss my arguments, not the number of lines of
Ada 95 you assume I have compiled.

Large-scale practical experience with a language cannot hurt, of
course, but (posited) lack thereof does not disqualify one from
talking about the language. If we took Prof. Dewar's advice literally,
there would be (among other extreme consequences) no room for
broad-ranging programming language surveys, since no one can be
a seasoned programmer in all of - say - Ada, Eiffel, Lisp, Tcl,
Visual Basic, Fortran 90, Snobol etc. Or, to continue the reductio
ad absurdum, one of the justly praised aspects of the original Ada
design was that it was heavily critiqued before it was finalized 
Applying the Dewar principle would have meant that none of that
criticism was meaningful, since none of the critics had any
extensive practice in the languages being discussed (especially
those that were rejected, so that no one ever wrote any
"substantial amount of real delivered product code" in them!).

"You can't criticize Y because you have not written at least
x lines of working Y code" is not a valid dismissal. If you
want to debate someone's conclusions, you have to do it on
the merits or demerits of his stated case. Otherwise we would
fall into ad hominem disputes - and, as we all know, this is not
permitted to happen on Usenet.

Thanks, by the way, for the nice comments about the book.

-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <Bertrand.Meyer@eiffel.com>
Web page: http://www.eiffel.com
OOSC-2 book info: http://www.eiffel.com/doc/oosc.html

Re: Inheritance versus Generics

[Robert A Duff]

In article <336596D9.2781E494@eiffel.com>,
Bertrand Meyer  <bertrand@eiffel.com> wrote:
>Large-scale practical experience with a language cannot hurt, of
>course, but (posited) lack thereof does not disqualify one from
>talking about the language. 

I tend to agree with Bertrand Meyer here.  I mean, I've criticized some
aspects of Eiffel without having written a line of code in Eiffel (well,
at least not something serious).  But I've at least read the language
definition carefully.

Perhaps Robert Dewar is (over)reacting to those who criticize Ada
without knowing the first thing about it.  I don't think Meyer is one of
those.

I can read a language definition (carefully), and feel some confidence
in criticizing it, despite the fact that I haven't invested several
years of my life programming in it.  Otherwise, how can we make progress
in language design?  There are thousands of languages out there -- the
best we can expect from language designers is to be familiar with them
by reading -- not direct experience.  Of course, there are those who
believe Ada or Eiffel or whatever to be the ultimate -- but they're
wrong; there's a lot of progress still to be made in this field.

>Thanks, by the way, for the nice comments about the book.

I liked your book, too.  :-)

- Bob

Re: Inheritance versus Generics

[Robert Dewar]

Bob Duff said

<<In article <336596D9.2781E494@eiffel.com>,
  Bertrand Meyer  <bertrand@eiffel.com> wrote:
  >Large-scale practical experience with a language cannot hurt, of
  >course, but (posited) lack thereof does not disqualify one from
  >talking about the language.

  I tend to agree with Bertrand Meyer here.  I mean, I've criticized some
  aspects of Eiffel without having written a line of code in Eiffel (well,
  at least not something serious).  But I've at least read the language
  definition carefully.

I am just stating a rule that comes from a lot of experience. I have
all too often seen experts in this field make statements about languages
they do not know well enough. Often these comments are just factually
incorrect. I could give lots of examples, with lots of famous names, but
that seems perhaps inappropriate :-)

Anyway, it is a rule I follow for myself. I have seen far too many people
who should know better make completely ridiculous statements about languages
they do not know well enough -- this is particularly true for lesser known
languages such as COBOL (I mean of course lesser known among the language
design crowd :-)

I have also seen plenty of absurd statements about C++ by Ada advocates,
and plenty of absurd statements about Ada by all sorts of people.

Anyway, I follow the rule myself, you won't see me criticizing Eiffel until
such time as I have done some substantial programming in that language for
example.

Yes, it makes it harder to compare languages, but I still find it a very
useful rule in filtering out objective observsations from subjective wishes.
Language design is full of advocacy from people who urgently wish language
X to be the best, and are consequently blinder than they should be to
shortcomings of X, and strenghts of (not X).

Going back to the quote, my concern is NOT with people who don't know
anything, it is with experts who just don't have enough working familiarity
with how a language is actually used in practice. This is a very important
aspect of understanding a language design. This cannot be obtained from
reading a reference manual.

  <<Perhaps Robert Dewar is (over)reacting to those who criticize Ada
  without knowing the first thing about it.  I don't think Meyer is one of
  those.>>


By the way, please note that I did not, and did not intend to specifically
suggest Betrand as someone who made incorrect statements, and I have made
no such statement. Bertrand added his own name to the thread in his
follow up :-) I certainly did not say that Bertrand knows nothing about
Ada, and I sure hope he did not take me to be saying that.

I also do not say that anything disqualifies anyone from talking about
anything! All I am saying is that I value comments more from people who
have the practical experience to go along with their theoretical 
understanding. And that I apply this to myself, so if you see a comment
from me criticizing a language, then it means I have written substantial
amounts of code in the language (substantial = for me large scale
delivered commercial code). 

(unless of course my evil twin brother has been masquerading as me again
and violating this rule :-)


Robert

Re: Inheritance versus Generics

[Jon S Anthony]

In article <336596D9.2781E494@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:

> Large-scale practical experience with a language cannot hurt, of
> course, but (posited) lack thereof does not disqualify one from
> talking about the language.

I must agree with you here - with one possible caveate (see below).


> Applying the Dewar principle would have meant that none of that
> criticism was meaningful, since none of the critics had any
> extensive practice in the languages being discussed (especially

Nicely done...


> "You can't criticize Y because you have not written at least
> x lines of working Y code" is not a valid dismissal. If you
> want to debate someone's conclusions, you have to do it on
> the merits or demerits of his stated case.

Right.  However, for this context there is one aspect that needs to be
watched out for when "failing the Dewar Principle".  That has to do
with differences of how a particular sort of goal is achieved in
different language designs.  In particular, a goal that is "handled"
by providing some sort of explicit support for that goal _can_ lead
the unwary into thinking that some sort of explicit construct for this
particular goal is necessary in order to achieve it.  And "thus" that
a languae without some directly corresponding construct can't achieve
it.  As we know this is not true (as it may well be covered by a more
general construct or an intended combination of some other
constructs), but I've seen this mistake made many times.  Multiple
inheritance is a favorite to trip over here.  "Friendship" and
"public,protected,private" are other typical examples.  As are
co,contra,and a-variance in class based OO.

Anyway, if you happen to have the luxury of engaging in the DP, then
it is much more likely that you will be aware of how such diverse
goals are easily handled (even without some explicit constructs
specifically for them).  This will "save" you from saying "X can't
accomplish Y because it does not have Z like R does", when X can in
fact easily accomplish Y...


> Otherwise we would fall into ad hominem disputes - and, as we all
> know, this is not permitted to happen on Usenet.

Hey, now don't you go dissing the grand tradition! :-)

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Inheritance versus Generics

[Robert Dewar]

<<> Applying the Dewar principle would have meant that none of that
> criticism was meaningful, since none of the critics had any
> extensive practice in the languages being discussed (especially
>>

Let me make a distinction here. Obviously one can discuss specific technical
aspects of a language without having written piles of code. For example,
given my experience, I would say it is a mistake to design a language
without recursion in its basic procedure invocation structure, and I would
consider that a legitimate specific criticism of COBOL, even by someone
who had not written piles of code in COBOL.

What is not legitimate is to make overall judgments of usability in general
or in specific domains. In other words, if you now carry that worry about
recursion in COBOL to make a statement that COBOL is not useful for
applicatoins in xxx domain, without having experience in how large COBOL
programs are written, then you are almost certainly speaking nonsense.

I was always amazed by how many people who did not know COBOL at all 
were surprised to find out that Realia COBOL was written 100% in COBOL.
They simply assumed that this would be tricky, and that we must have had
great difficulty doing this. Complete nonsense of course -- I would far
rather write a compiler in COBOL than in C (and that is based on having
done both!) Indeed, let's take the recursion example. One might assume
that lack of recursion in a language would be a nuiscance, especially
when compiling a language like COBOL with a heavily recursive syntax.

In fact in the kind of domain we were working in, with a limited memory,
it is always a bad idea to use recursion in a compiler, since it introduces
complexity limits into programs that are induced by the maximum memory
available (Realia COBOL is one of the very few compilers I know of that
has aboslutely NO limits of any kind other than available disk space, and
in an environment with only 200K or so of available memory (no virtual
memory around) can compile programs that are millions of lines long.

Re: Inheritance versus Generics

[bertrand]

 Mats Weber as quoted by Matthew Heaney:
>
> >You can simulate generics with inheritance (the technique is described
> >in Meyer's "Object Oriented Software Construction"

Just a small clarification: the discussion (appendix B in the
recent edition of my book, entitled "Genericity vs. Inheritance"
and the n-th iteration of an article originally in the first
OOPSLA conference in 1986) shows that inheritance
can simulate some aspects of genericity, but not all,
and that genericity by itself can
only cover a small part of inheritance. On the basis of this
analysis it concludes that one needs both mechanisms, and deduces
the precise combination that appears adequate to cover all
needs at minimal complexity.

> P.S. He actually has a link to your dissertation in his book, Mats.

Right... I must say I am impressed by the amount and quality of
Ada 95-related material available on the Web.

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet

Re: Inheritance versus Generics

[Robert Dewar]

Bertrand said

<<Just a small clarification: the discussion (appendix B in the
recent edition of my book, entitled "Genericity vs. Inheritance"
and the n-th iteration of an article originally in the first
OOPSLA conference in 1986) shows that inheritance
can simulate some aspects of genericity, but not all,
and that genericity by itself can
only cover a small part of inheritance. On the basis of this
analysis it concludes that one needs both mechanisms, and deduces
the precise combination that appears adequate to cover all
needs at minimal complexity.>>


It is always tempting to try to unify features in programming languages
which seem related, and it has always been tempting for designers to try
to avoid having both inheritance and genericity, but given the very clear
attempts that have been rethought (C++ adding templates, and Ada adding
generalized inheritance), it really seems like we cannot avoid having
both facilities. Bertrand's argument is certainly convincing, but in a
way it is even more convincing when advocates of the contrary viewpoint
come to change their mind.

My view is that at this stage, any language not providing effective
facilities in both departments is definitely decrepit (you may make
up your own list of languages that are thus declared decrepit, or
perhaps, with less flowery language, lacking :-) -- one interesting
entry on that list is OO-COBOL, which has remarkably powerful OO
features, including full inheritance, but completely lacks genericity
(well I suppose you can use COPY REPLACING for a very limited version
of text oriented macros to address some subset of the problem ...)

Robert Dewar

Re: Inheritance versus Generics

[Lionel Draghi]

Craig Smith wrote:
> 
> Generics were a very power feature of Ada-83.  With the OO features
> introduced into Ada-95 (in particuliar, the tagged record and ability to
> inherit), are Generics obsolute? 
...

Clearly not, generics are even used by Ada 95 to provide certain kind of
inheritance :-)

I think this is a design issue : Inheritance and genericity have
different use,
and this justify existence of both :
- when you need to factorize common "properties" between related object,
you
should use inheritance, and build classes.
- when you need to factorize some algorythm between object possibly
without any
relation, you should use genericity.

Inheritance imply the "is a kind of" relation, Genericity do not.

D'accord ou pas? :-)

________________________________________________________________________________
Lionel Draghi               01 45 28 88 50                 17, rue Simon
Dereure
                                                          93 110
Rosny-sous-Bois
                                                                         
France

http://ada.eu.org/                                      
http://www.adahome.com/

Re: Inheritance versus Generics

[Robert Dewar]

Craig Smith asks

<<Generics were a very power feature of Ada-83.  With the OO features
introduced into Ada-95 (in particuliar, the tagged record and ability to
inherit), are Generics obsolute?  I would guess since several features
were added to generics (like generic formal package parameters), the
answer is no.  Does anyone have any thoughts on this?>>

One group that has thoughts on this is the C++ design committee. Originally
the attempt was to develop OO stuff, and decide that genericity was not
needed, but eventually it was clear that this was over-restrictive, and
so genericity (templates) was added.

Note that the Ada 83 design is an interesting dual. The Ada 83 design
committee was well aware of the object oriented approach (many of them
had been using Simula-67 for over a decade -- it is well to remember
that the basic OO idea are ancient). Their experience said that writing
large scale programs using the OO approach was ineffective, and they
very conciously decided against incorporating such features into Ada 83,
deciding that the same basic functionality could be achieved in a language
that concentrated on providing powerful genericty.

Now at least in some sense, Ada 95, shows the same phenomenon as C++,
in deciding that both are necessary. However, the situation in the Ada 95
case is a little more clouded, since the basic motivation for adding OO
stuff was not purely technial, but the decision was largely driven by
"following the trend" fadism. Only time will tell the full story here ...

A lot of people find genericity to be much more significant than OO stuff
(a good example of this is the designers of the standard template library
in C++, which uses genericity extnsively, but inheritance barely at all.

Re: Inheritance versus Generics

[Michael F Brenner]

Robert said:
    > The Ada 83 design
    > committee was well aware of the object oriented approach (many of them
    > had been using Simula-67 for over a decade -- it is well to remember
    > that the basic OO idea are ancient). Their experience said that writing
    > large scale programs using the OO approach was ineffective, and they
    > very conciously decided against incorporating such features into Ada 83,
    > deciding that the same basic functionality could be achieved in a 
    > language that concentrated on providing powerful genericty.

May I add that the same functionality would have been achieved had packages 
been either first class (makable into arrays) or second class (passable
as generic parameters) objects.

Re: Inheritance versus Generics

[Robert Dewar]

Michael said

<<May I add that the same functionality would have been achieved had packages
been either first class (makable into arrays) or second class (passable
as generic parameters) objects.>>

I assume you are aware of all the subtle semantic problems in doing this.
This is an issue that has been discussed very extensively during the
design process, and the issues are well known and well understood, and
the consensus was that package types are simply too much additional 
complexity ...

Re: Inheritance versus Generics

[Nick Roberts]

Surely the most fundamental capability introduced by the O. O. features of
Ada 95 is dynamic dispatching. Is there a viable alternative way to provide
the same functionality?

Also, fill me in a little on the idea of arrays of packages, please. This
seems like a weird concept to li'l ol' me (but interesting).

Nick.

Re: Inheritance versus Generics

[Michael F Brenner]

    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. 
.

Re: Inheritance versus Generics

[John G. Volan]

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? :-) ");
------------------------------------------------------------------------

Re: Inheritance versus Generics

[Nick Roberts]

Michael F Brenner <mfb@mbunix.mitre.org> wrote in article
<5k5suu$bhj@top.mitre.org> an excellent article about arrays of packages,
and packages as First Class Objects. Many thanks, Michael.

I would wholeheartedly agree that it is a great pity that Ada 95 did not
include some sort of facility for the dynamic manipulation of package
binding. Naturally, this facility would imply a variety of implementation
difficulties. It would be difficult (or impossible) to implement
dynamically bindable packages as efficiently as statically bound ones.
Nevertheless, the speed penalty would, in many cases, be acceptable, and
the advantages of such a facility would often be considerable.

This may sound surprising, coming from such a technologically conservative
person as myself, but I think I would go so far as to say that this is a
serious omission, and not one to be lightly brushed aside.

Nick.

Re: Inheritance versus Generics

[Robert Dewar]

Nick said

<<This may sound surprising, coming from such a technologically conservative
person as myself, but I think I would go so far as to say that this is a
serious omission, and not one to be lightly brushed aside.>>

Actually the light brushing here seems to be more on your side. Yes, the idea
of making packages first class is superficially appealing, and it certainly
was not "lighly brushed aside", but was on the contrary carefully examined
over a long period of time by a lot of people. In the light of that
discussion, the great majority of the DR's (really everyone except Tony
Luckham, who subsequently dropped out) decided that the added complexity
was not worth the functoinality, which we felt could be adfequately
obtained in other ways without introducing as much complexity.

So you may or may not agree with this, but should probably examine the
issue in more detail. it is a deep one!

Re: Inheritance versus Generics

[Mats Weber]

Robert Dewar wrote:
> 
> Michael said
> 
> <<May I add that the same functionality would have been achieved had packages
> been either first class (makable into arrays) or second class (passable
> as generic parameters) objects.>>
> 
> I assume you are aware of all the subtle semantic problems in doing this.
> This is an issue that has been discussed very extensively during the
> design process, and the issues are well known and well understood, and
> the consensus was that package types are simply too much additional
> complexity ...

I have done some extensive work on that topic (package types as
classes), and I disagree. You can find my proposal at
<http://lglwww.epfl.ch/Team/MW/Ada-Extensions/Ada-Extensions.html>

On the other hand, I would be very interested in knowing the arguments
that lead to the consensus that rejected package types. Is there a
paper, report, or anything ?

Re: Inheritance versus Generics

[Robert Dewar]

Mats said, replying to me

<<> I assume you are aware of all the subtle semantic problems in doing this.
> This is an issue that has been discussed very extensively during the
> design process, and the issues are well known and well understood, and
> the consensus was that package types are simply too much additional
> complexity ...

I have done some extensive work on that topic (package types as
classes), and I disagree. You can find my proposal at
<http://lglwww.epfl.ch/Team/MW/Ada-Extensions/Ada-Extensions.html>>>>

I think your language is a little imprecise here, I think you are saying that
you disagree with the consensus, not that anything I said is wrong (this
issue WAS debated extensively -- extensively enough that I certainly don't
feel like any more technical talk on it :-) -- and there was a consensus
that it was a bad idea.

Sure there is a small (very noisy :-) minority that disagreed, but it 
was a very small minority (the notable member of this minority was
Tony Luckham, if you want to track down a kindred spirit on this issue).
 (and of course there was the Intel compiler ...)

Re: Inheritance versus Generics

[Michael Feldman]

A Few "Sound Bites" on Object-Oriented Programming
Michael B. Feldman
The George Washington University

-------------------------------------------------------------

"My guess is that object-oriented programming will be in the
1980s what structured programming was in the 1970s.
Everyone will be in favor of it. Every manufacturer will
promote his products as supporting it. Every manager will
pay lip service to it. Every programmer will practice it
(differently). And no one will know just what it is."

Tim Rentsch 1982 (one of the original Xerox Smalltalkers)
(as quoted by Booch)

-------------------------------------------------------------

"Everything is an object these days; if it doesn't have
o-b-j-e-c-t in the name, it won't sell...OOT is so
radically different that we must break and reset
programmers' coding hands before they can write
object-oriented instead of procedural programs. This is
much worse than the structured programming hoopla of the
1970s...If we convert one Cobol programmer per minute to
Smalltalk, we should have a revolution by the time Capt.
Kirk and the USS Enterprise return from Vulca on impulse
power."

Ted Lewis, "The Dark Side of Objects", IEEE Computer, Dec.
1994.


-------------------------------------------------------------
Composition vs. Classification

(paraphrasing here)

Objects gather both data structures and program structures.

Classification: objects are organized in a hierarchy of
classes. General classes contain features common to many
subclasses, and specalized subclasses implement only
behaviors that are common to a subset of the parent class's
objects.

Composition: objects are made of different parts, and that
the same parts can be used to make a variety of
higher-level objects. Each object is designed as an
assembly of lower-level components. There is no need to
know how a component is made in order to use it.

A set of parts that form an object constitutes an
abstraction layer. This is what is generally used in
engineering, and has been especially successful in the
electronic industry.

(quoting directly here)

"Why do so many people believe that classification is the
only 'true' object orientation? Perhaps because OOL
designers place a heavy emphasis on inheritance, which is
clearly necessary only to classification."

J-P Rosen, "What Orientation Should Ada Objects Take?"
Communications of the ACM,  Nov. 1992


-------------------------------------------------------------

"There is a very real tension between inheritance and
encapsulation. To a large degree, the use of inheritance
exposes some of the secrets of an inherited class.
Practically, this means that to understand the meaning of a
particular class, you must often study all of its
superclasses, sometimes including their inside views."

Grady Booch, Object-Oriented Design with Applications,
Benjamin Cummings, 1991.

-------------------------------------------------------------


"OOT has a nasty 'fragile base class problem,' which means
that once a program is designed and implemented as a class
hierarchy, it is maximally coupled. Changing one interface
specification brings the whole house of cards tumbling
down. We were warned against this in 1975 (minimize
coupling, maximize cohesion). Coupling is a serious
maintenance nightmare that bit Mentor Graphics (Falcon
Framework) in the bottom line. How many other software
companies are headed for OOT malaise?"

Lewis, op. cit.

-------------------------------------------------------------

"[I]nheritance is often used not for classification, but
just to grab pieces of code. . .makes a class PARROT
inherit from the class HUMAN-BEING because it needs the
property CAN-SPEAK. This kind of misuse of the inheritance
mechanism, especially when multiple inheritance is
available, is extremely tempting to the programmer who just
wants to 'reuse' existing code, while actually introducing
a terrible mess in the dependencies between objects.

...

"In the slums, people build houses by reusing old items
such as pieces of wood and tires, and adjusting them to
their needs. This kind of reuse is often extremely clever,
and if you absoutely need a shelter rapidly, it is
certainly an efficient method. But will the house withstand
a storm? This is certainly not industrial reuse, which is
building houses from well-engineered, standard
prefabricated components.

...

"Ada object orientation will still not just follow
classification, because classification does not answer
properly a number of requirements for Ada applications. In
general, classification will favor ease of design and
rapidly varying specifications such as those encountered
when prototyping software, while composition will better
match the needs of secure, long-lasting systems, requiring
various implementations of the same abstract behavior."

J-P Rosen, op. cit.

-------------------------------------------------------------


"-- Most past progress in software productivity has come
from eliminating non-inherent difficulties such as awkward
machine languages and slow batch turnaround.

"-- There are not a lot more of these easy pickings.

"-- Radical progress is going to have to come from
attacking the essential difficulties of fashioning complex
conceptual constructs.

"The most obvious way to do this recognizes that programs
are made up of conceptual chunks much larger than the
individual high-level language statement -- subroutines, or
modules, or classes. If we can limit design and building so
that we only do the putting together and parameterization
of such chunks from prebuilt collections, we have radically
raised the conceptual level, and eliminated the vast
amounts of work and the copious opportunities for error
that dwell at the individual statement level.

"Parnas's information-hiding definition of modules is the
first published step in that crucially important research
program, and it is an intellectlual ancestor of
object-oriented programming He defined a module as a
software entity with its own data model and its own set of
operations. Its data can only be accessed via one of its
proper operations.

"The second step was a contribution of several thinkers:
the upgrading of the Parnas module into an abstract data
type, from which many objects could be derived. The
abstract data type provides a uniform way of thinking about
and specifying module interfaces, and an access discipline
that is easy to enforce.

"The third step, object-oriented programming, introduces
the powerful concept of inheritance, whereby classes (data
types) take as defaults specified attributes of their
ancestors in the class hierarchy. Most of what we hope to
gain from object-oriented programming derives in fact from
the first step, module encapsulation, plus the idea of
prebuilt libraries or modules or classes that are designed
and tested for reuse."

Fred Brooks, "The Mythical Man-Month after 20 Years", IEEE
Computer, Sept. 1995.

-------------------------------------------------------------

"Unfortunately for the information technology industry, many
object technology (OT) gurus are still touting the role of
inheritance and subclassing in building reusable business
objects. One well-designed parent, they say, such as a
Customer object, allows developers to effortlessly spawn
dozens of reusable kin. These theories of inheritance sound
pretty good-until you try applying them to building an
industrial -strength application .

"We have spent more than 150 work-years tackling this issue
and many others related to building commercial
object-oriented systems. The verdict on inheritance and
reuse? Uncontrolled and unplanned subclassing results in
code as fragile and hard to maintain as the COBOL programs
we're replacing. Moreover, subclassing often is
counterproductive. Inheritance, by its nature, means
changing the objects designed to be reused, which will
cancel out any benefits of reuse because each new
subclassed object then requires testing, the biggest drag
on rapid development. Our internal studies show that as
much as 60% of the total implementation effort for a
client/server system is spent on testing.

"The best approach is to treat inheritance as a power tool
for churning out objects when appropriate. Inheritance can
give you a boost in programmer productivity, but it won't
make possible the high degree of reuse that delivers the
vital combinition of speed, agility, and power that today's
business systems need.

"That's the crucial equation for making information
technology work: speed + agility + power. By speed, we mean
the overall productivity gains from building applications
from a store of reusable objects. Power means using the
computer to do things that couldn't be done
before-integrating hypertext, graphics, video, and
Integrated Performance Support, which transmit more
information in new ways to knowledge workers. We use the
term "agility" because it conveys much more than
"flexibility," a feature of object technology comnioiily
associated with ease of maintenance. While flexibility-the
system's ability to be adapted to new or changing
specs-remains all important goal for software, agility
refers to the organization as a whole and its ability to
change processes and strategies with the nimbleness of a
small company.

"To build these types of solutions, look to encapsulation.
Encapsulation provides for more useful reuse than
inheritance because it reduces testing, not just
programming. Encapsulated objects project abstract business
traits that make them valuable (and reusable!), rather-
than inheriting and propagating inflexible, un-reusable
code. Moreover, this approach to reuse adds for more value
than inheritance does to object-oriented design because it
delivers the agile systems organizations need to support
continuous reengineering and capitalize on its
benefits-accelerating new services and products to market,
increasing responsiveness to customers, and supporting new
processes and global operations."

Jim Adamczyk and Tom Moldauer (Andersen Consulting) 
Object Magazine, Sept. 1995

Re: Inheritance versus Generics

[Martin Lorentzon]

Craig Smith <cdsmith0@flash.net> writes:

> Generics were a very power feature of Ada-83.  With the OO features
> introduced into Ada-95 (in particuliar, the tagged record and ability to
> inherit), are Generics obsolute?  I would guess since several features
> were added to generics (like generic formal package parameters), the
> answer is no.  Does anyone have any thoughts on this?

Mastering both features can prove very powerful. Parametrization can
be used to reduce the length/complexity of the inheritance lattice of
your system. 

I've found that parametrization is often used to end an inheritance
lattice.

/Martin Lorentzson

Re: Inheritance versus Generics

[tmoran]

In <5juemo$bca@felix.seas.gwu.edu> Michael Feldman gives
>A Few "Sound Bites" on Object-Oriented Programming
  After about 9 months of fairly heavy use of tagged types, it seems
to me that they are a powerful tool, but tend easily to lead away
from correctness, understandability, and reusability.
  It's easy to wind up calling a different routine than you thought.
  It can be difficult to realize that you're calling the wrong routine.
  Base types easily have too many primitives, and each generation of
descendants adds a few, resulting in a supposeduly reusable
encapsulated component that has a very large 'surface area' that the
re-user must understand. At each generation the conceptual nature
of the object tends to be slightly distorted (analogous to the
transmission of rumors), and these minor distortions tend to add
up to significant changes in the original concept.  It may develop
that the newer generations, and the uses of their objects, show
the Ur-object to be less than ideal, but it's much too late to change.
  Orthogonally, there is a problem with the mushiness of the word
'object' in the industry.  Thus in MS Windows, an 'object' more or
less means 'a handle to a private data record'.  These have somewhat
different behavior than one might expect an abstract 'menu object'
or 'pen object' to have.  Another source of confusion and thus error.
  Inheritance does allow some powerful ways of doing things, and
perhaps after 5-10 years, when the next Silver Bullet comes along,
we will all use OO flawlessly.  ;)

Re: Inheritance versus Generics

[tmoran]

>I can read a language definition (carefully), and feel some confidence
>in criticizing it, despite the fact that I haven't invested several
>years of my life programming in it.  Otherwise, how can we make progress
>in language design?  There are thousands of languages out there -- the
>best we can expect from language designers is to be familiar with them
>by reading -- not direct experience.  Of course, there are those who
  There is a third alternative:  look at the results of thousands of
real programmers using the language.  It may be impractical for language
designers to have lots of direct experience in lots of languages, but
the history of science since the Greeks suggests there are real limits
on how far you can get by merely writing about other's ideas, without
going into the real world and trying out your ideas to see how they work
in practice.
  Take a look at "Strategic Directions in Programming Languages" in the
new ACM Computing Surveys.  Under "Exceptions", it says "introduced in
PL/1 but extensively studied and formalized in ML; similar concepts
appeared later in C++."  Did the "extensive study and formalization" in
ML include having thousands of real programmers, of varying excellence,
write millions of lines of code using exceptions in various
idiosyncratic ways, thus providing grist for the language designers to
fine tune the syntax, semantics, and guidelines about exceptions?