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.8 required=5.0 tests=BAYES_00,INVALID_MSGID, SUBJ_ALL_CAPS autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,4873305131bf4d94 X-Google-Attributes: gid103376,public X-Google-Thread: fdb77,4873305131bf4d94 X-Google-Attributes: gidfdb77,public X-Google-Thread: 109fba,4873305131bf4d94 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,4873305131bf4d94 X-Google-Attributes: gid1014db,public From: mw@ipx2.rz.uni-mannheim.de (Marc Wachowitz) Subject: Re: ADA SUCKS, C/C++/JAVA RULES!!!! Date: 1997/11/11 Message-ID: <64a739$oc1$1@trumpet.uni-mannheim.de>#1/1 X-Deja-AN: 288663785 Organization: --- Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.lang.java.advocacy Date: 1997-11-11T00:00:00+00:00 List-Id: 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