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: Bertrand Meyer Subject: Re: OO, C++, and something much better! Date: 1997/01/07 Message-ID: <32D2E6C8.13728473@eiffel.com>#1/1 X-Deja-AN: 208387045 references: <32CCE4ED.6A21@online.no> <5ajo99$khu@panix.com> <32ce7009.280817694@news.zip.com.au> <32D0CA27.44C2@ghgcorp.com> <32D245D5.2C0@ghgcorp.com> content-type: text/plain; charset=us-ascii organization: Interactive Software Engineering Inc. 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.0Gold (X11; I; SunOS 4.1.3 sun4c) Date: 1997-01-07T00:00:00+00:00 List-Id: 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. - 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. - 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.) - 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