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: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public From: mheaney@ni.net (Matthew Heaney) Subject: Re: OO, C++, and something much better! Date: 1997/01/08 Message-ID: #1/1 X-Deja-AN: 208621901 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=ISO-8859-1 organization: Estormza Software mime-version: 1.0 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: In article <32D2E6C8.13728473@eiffel.com>, 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. Ada has had that ability since the original standard: generic type List_Item is private; package Lists is type List is private; procedure Add (Item : in List_Item; To : in out List); ... > > - 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. There are 2 ways of doing that in Ada 95. The first (what you could already do in Ada 83) is to require that the type have a comparison operator: generic type List_Item is private; with function "<" (Left, Right : List_Item) return Boolean is <>; package Sorted_Lists is type List is private; ... The second (new to Ada 95) is to require that the type inherit from another: package P is type T is tagged private; function "<" (L, R : T) return Boolean; ... end P; with P; generic type List_Item is new P.T; package Sorted_Lists is type List is private; ... >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. I can instantiate my first sorted list package, because type Integer comes predefined with a comparison operator. with Sorted_Lists; package Integer_Sorted_Lists is new Sorted_Lists (Integer); > >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. If tennis player has a comparison operator, then I can use sorted_list version 1. If tennis player derives from P.T, and I can use either sorted list version 1 or 2. >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. Technically, I should modify the sorted list as follows: generic type List_Item is private; with function "=" (L, R : List_Item) return Boolean is <>; with function "<" (L, R : List_Item) return Boolean is <>; package Sorted_Lists is ...; That way I can let the client pass in his "=" method that replaced the predefined one for unlimited (private) types. >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. As you can in Ada. >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. P.J. Plauger once refered to C++ as having "ugly pragmatism." I would say about Ada 95 that it has "beautiful pragmatism." We humans bandy about terms like "purity," but there's no such thing in Nature; she only cares about what works. I think there's room for pragmatism, though C++ probably pushes that argument a bit too far. N'est-ce pas? matt -------------------------------------------------------------------- Matthew Heaney Software Development Consultant (818) 985-1271