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: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: eachus@spectre.mitre.org (Robert I. Eachus) Subject: Re: OO, C++, and something much better! Date: 1997/01/08 Message-ID: #1/1 X-Deja-AN: 208553598 references: organization: The Mitre Corp., Bedford, MA. newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng Date: 1997-01-08T00:00:00+00:00 List-Id: Bertrand Meyer said: > In my opinion neither Ada (83 or 95) nor C++ has the combination > of mechanisms making it possible to have the full power of > generics in an object-oriented language, as present in Eiffel... And then listed four properties, all of which are in Ada 95! There are differences between Ada 95 and Eiffel, for example in the way multiple inheritance is handled. The biggest difference though is that the type system is normally viewed as a forest rather than a single tree. These differences do affect the way in which these things are usually implemented, but they do lead to major differences in the way the features are normally used. (To avoid flames from both sides: see "normally viewed" and "usually implemented" above. I'm talking about how generics tend to be used, not about limitations--in either language.) For example, in Ada you would not require a class to be derived from COMPARABLE if you wanted to insure that comparisons work, you would more likely require the comparison operations directly. (See below.) This is usually the "right" way to do it in Ada for technical reasons, but the real reason is that the Ada mindset sees classes as not strictly hierarchical but as a set of non-exclusive groupings. i.e. Just as it is sensible to ask if type A is in class B, it is also sensible in Ada to ask or specify if a type has discriminants or if a subtype is definite. A good working definition of a class in Ada is the set of all types that match a particular generic formal part: type Foo is range <>; -- integer class type Fubar(<>) is limited private; -- The class of all classes. type Bar is new Foob with private; -- Foob'CLASS (for -- non-Ada programmers, Foob, a tagged type, or any type -- derived directly or indirectly from it.) -- for completeness: type Barf is new Foobar; -- same as above, but Barf must -- be definite. type Element is private; with function "<" (L,R: Element) return Boolean is <>; -- Any ordered type with assignment and equality. And so on... -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is...