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: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: Ken Garlington Subject: Re: OO, C++, and something much better! Date: 1997/01/08 Message-ID: <32D3FDFB.3665@lmtas.lmco.com>#1/1 X-Deja-AN: 208499265 references: <32CCE4ED.6A21@online.no> <5ajo99$khu@panix.com> <32ce7009.280817694@news.zip.com.au> <32D0CA27.44C2@ghgcorp.com> <32D245D5.2C0@ghgcorp.com> <32D2E6C8.13728473@eiffel.com> content-type: text/plain; charset=us-ascii organization: Lockheed Martin Tactical Aircraft Systems mime-version: 1.0 newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng x-mailer: Mozilla 3.01 (Win95; U) Date: 1997-01-08T00:00:00+00:00 List-Id: Bertrand Meyer wrote: > > 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: > > - Unconstrained genericity, to declare a class > as e.g. LIST [G], where G represents an arbitrary > type, so that you can then use LIST [SOME_TYPE] regardless > of what SOME_TYPE is. I've seen Mr. Meyer mention this in various articles, but I've never understood it. What's the distinction between an Ada generic with a limited private type as a parameter, and an "unconstrained" generic? > - Constrained genericity, as in e.g. > SORTED_LIST [G -> COMPARABLE], to require that > some operations be applicable to all actual > generic parameters. The rule is that > SORTED_LIST [SOME_TYPE] is permitted if and only > if SOME_TYPE inherits, directly or indirectly from > COMPARABLE. The -> symbol is evocative of the symbol > for inheritance used in class diagrams in e.g. B.O.N. > Within the class SORTED_LIST, any operation (feature, method) > of class COMPARABLE, such as infix "<" etc., is then applicable > to entities of type G. Isn't this also available in Ada? In particular, can't you require the user to provide the needed operations in the absence of visible defaults? > - A completely consistent type structure, in which > even basic types such as INTEGER are classes, > present in the general inheritance structure. > (In C++ or Java, for example, the basic types > are completely separate from the class and inheritance > structure.) I also thought this was true of Ada. Isn't Integer actually considered part of the general inheritance structure of the root_integer class? [LRM 3.5.4:14?] > - True static typing (with no cast a la C++). > > So in the constrained genericity case SORTED_LIST [INTEGER] > will be permitted, since COMPARABLE is indeed an existing class, > describing order relations and part of the Eiffel Library > Kernel Standard, and INTEGER (also part of ELKS) does inherit > from COMPARABLE. > > SORTED_LIST [TENNIS_PLAYER] will also be > valid, assuming the user-defined class TENNIS_PLAYER inherits > from COMPARABLE. But something like SORTED_LIST [COMPLEX] > will be rejected by the compiler, assuming COMPLEX is not > a descendant of COMPARABLE. > > In the unconstrained case, a declaration such as LIST [G] > is understood as an abbreviation for LIST [G -> ANY], where > ANY is the ELKS class inherited by all classes. This makes > it possible to apply objects of type G a wide range of operations > applicable to all objects: equality comparison (redefinable > in any class as long as it satisfies the original assertions), > copying, cloning, even (in the latest version of ELKS) hash > coding. > > Without going into the details, I should add that Eiffel's design > for generics avoids the grave problems that one reads about in > connection with C++ templates: the need in C++ to generate code > separately > for each generic derivation (each new actual generic parameter), with > its > rather bad effect on compilation time ("template instantiation problem") > and, as a result, the advice regularly given in the C++ literature > to avoid using templates too much. In Eiffel, you can generate > code just once (with some specific optimizations for basic types), > without having to pay any performance overhead either at compile > time or at run time. So you can use genericity as much as you like. > The ISE Eiffel libraries, for example, are generic throughout. > > > In comparison with Eiffel, not even mentioning Java with its total lack > of genericity, the other attempts at generic mechanisms that I have seen > in an O-O context look to me rather half-hearted. > > I think Eiffel's consistent and complete treatment of genericity and > inheritance is one of the reasons why some of the biggest successful > industrial O-O projects have been produced in Eiffel. When the goal is > not just to play around, but to build large, mission-critical systems, > one needs the right combination of mechanisms, not just a partial > attempt. > > For details about the Eiffel mechanism see the Eiffel language tutorial > at > http://www.eiffel.com. > > -- > Bertrand Meyer, President, ISE Inc., Santa Barbara (California) > 805-685-1006, fax 805-685-6869, - > ftp://ftp.eiffel.com > Visit our Web page: http://www.eiffel.com (WITH FRAMES) > or http://www.eiffel.com/noframes.html -- LMTAS - The Fighter Enterprise - "Our Brand Means Quality" For job listings, other info: http://www.lmtas.com or http://www.lmco.com