Re: ADA SUCKS, C/C++/JAVA RULES!!!!

[mw@ipx2.rz.uni-mannheim.de (Marc Wachowitz)]

kennel@nospam.lyapunov.ucsd.edu (Matt Kennel (Remove 'NOSPAM' to reply)) wrote:
> I think it's perfectly OK to admit most of the truth that there was no clean
> way to do MI in a language which included most of Ada83 and its module
> system as an intellectual base.

Nothing against admitting this in case it truly was the reason, but I
don't see why it would be true. In fact, off the top of my head I could
think of several different approaches to integrating MI - be it multiple
interface inheritance with single code inheritance, or full multiple
code inheritance - with "OO-less Ada95". Of course, different people's
interpretations of what "clean" means in our context vary considerably.

I wouldn't like to try and please a fanatic "OO-purist" (bad misnomer,
but established by a bad tradition) who will only accept something as
"clean OO" if it looks pretty much like his beloved programming language
(be that Self or Smalltalk or Eiffel or Common Lisp's object system or
whatever else), but given what I'd expect about someone who generally
likes Ada (particularly its emphasis on readability and explicitness
vs. ease/compactness of writing, and the freedom to chose among design
alternatives), I think it would have been possible to find something
consistent with these tendencies and workable in practice. Basically I'd
go for a delegation-like model, where overriding is only possible with
the routines marked as such, and the decision whether or not to override
something must be explicit, such that with every subtype there's a list
of all available methods; thus any new method in a supertype would trigger
the need in subtypes to consider whether that new method would be used as
provided, or redefined, or that particular subtyping ceases to make sense.
Another approach would be to establish messages as declarations in their
own right, not inherently associated with types, and then define subtyping
as relation on the set of handled messages, where again handlers would be
required to be explicit. This way one could avoid name clashes or repeated
inheritance, not having to make up complicated solutions for problems which
don't occur in the first place. The design space is really quite large,
much richer than only the more popular models of Java, C++ or Eiffel.

My impression is indeed that the Ada language-design tradition tends to
be conservative about inventing unconventional "big models" - like some
very unusual form of OO - but will rather provide well-established features
(perhaps combined in a way which was previously not common) and building
blocks - which can be used in lots of different situations - for a variety
of designs, and I have no reasons to doubt that the original description
why MI was left out is true.

-- Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>