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.9 required=5.0 tests=BAYES_00 autolearn=ham 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: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,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: Kohler Markus Subject: Re: OO, C++, and something much better! Date: 1997/01/08 Message-ID: X-Deja-AN: 208616624 references: organization: Hewlett Packard GmbH Germany 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" == Bertrand Meyer writes: Bertrand> In my opinion neither Ada (83 or 95) nor C++ has the Bertrand> combination of mechanisms making it possible to have the Bertrand> full power of generics in an object-oriented language, Bertrand> as present in Eiffel: In my opinion and not only in my opinion Eiffel has NOT the full power of generics. Let me cite David L. Shang : "Unlike Eiffel, Transframe does not require runtime type checks to eliminate holes (a hole is defined as a leak in the specification through which an argument can pass the check but the type of the argument is actually wrong) in the supertype's interface. Instead it requires a runtime type check merely for flexibility in heterogeneous programming, which is exactly the case forbidden by some other approaches. Class parameters can be used to express type dependencies. And thanks to the type dependency check via type assurance, a compiled Transframe program will never report a runtime type error. Eiffel allows fields/methods in subclasses to be redefined by subtypes, which is a more flexible type system than that of C++. Eiffel allows covariant changes to types of instance variables and, as a result, it is not statically type-safe. A system-level type check is required but only works with a closed-world assumption. It seems that Eiffel's newly proposed type checking rule is too conservative to include a useful usage of covariance. " See http://www.sigs.com/publications/docs/oc/9608/oc9608.c.shang.html for more information. Bertrand> - Unconstrained genericity, to declare a class as Bertrand> e.g. LIST [G], where G represents an arbitrary type, so Bertrand> that you can then use LIST [SOME_TYPE] regardless of Bertrand> what SOME_TYPE is. Bertrand> - Constrained genericity, as in e.g. SORTED_LIST [G Bertrand> -> COMPARABLE], to require that some operations be Bertrand> applicable to all actual generic parameters. The rule is Bertrand> that SORTED_LIST [SOME_TYPE] is permitted if and only if Bertrand> SOME_TYPE inherits, directly or indirectly from Bertrand> COMPARABLE. The -> symbol is evocative of the symbol for Bertrand> inheritance used in class diagrams in e.g. B.O.N. Bertrand> Within the class SORTED_LIST, any operation (feature, Bertrand> method) of class COMPARABLE, such as infix "<" etc., is Bertrand> then applicable to entities of type G. Bertrand> - A completely consistent type structure, in which Bertrand> even basic types such as INTEGER are classes, present in Bertrand> the general inheritance structure. (In C++ or Java, for Bertrand> example, the basic types are completely separate from Bertrand> the class and inheritance structure.) Bertrand> - True static typing (with no cast a la C++). Bertrand> So in the constrained genericity case SORTED_LIST Bertrand> [INTEGER] will be permitted, since COMPARABLE is indeed Bertrand> an existing class, describing order relations and part Bertrand> of the Eiffel Library Kernel Standard, and INTEGER (also Bertrand> part of ELKS) does inherit from COMPARABLE. Bertrand> SORTED_LIST [TENNIS_PLAYER] will also be valid, assuming Bertrand> the user-defined class TENNIS_PLAYER inherits from Bertrand> COMPARABLE. But something like SORTED_LIST [COMPLEX] Bertrand> will be rejected by the compiler, assuming COMPLEX is Bertrand> not a descendant of COMPARABLE. Bertrand> In the unconstrained case, a declaration such as LIST Bertrand> [G] is understood as an abbreviation for LIST [G -> Bertrand> ANY], where ANY is the ELKS class inherited by all Bertrand> classes. This makes it possible to apply objects of type Bertrand> G a wide range of operations applicable to all objects: Bertrand> equality comparison (redefinable in any class as long as Bertrand> it satisfies the original assertions), copying, cloning, Bertrand> even (in the latest version of ELKS) hash coding. Bertrand> Without going into the details, I should add that Bertrand> Eiffel's design for generics avoids the grave problems Bertrand> that one reads about in connection with C++ templates: C++ templates are far from beeing perfect, that's true. Bertrand> the need in C++ to generate code separately for each Bertrand> generic derivation (each new actual generic parameter), Bertrand> with its rather bad effect on compilation time Bertrand> ("template instantiation problem") and, as a result, the Bertrand> advice regularly given in the C++ literature to avoid Bertrand> using templates too much. In Eiffel, you can generate Bertrand> code just once (with some specific optimizations for Bertrand> basic types), without having to pay any performance Bertrand> overhead either at compile time or at run time. So you Bertrand> can use genericity as much as you like. The ISE Eiffel Bertrand> libraries, for example, are generic throughout. Bertrand> In comparison with Eiffel, not even mentioning Java with Bertrand> its total lack of genericity, the other attempts at Bertrand> generic mechanisms that I have seen in an O-O context Bertrand> look to me rather half-hearted. Bertrand> I think Eiffel's consistent and complete treatment of Bertrand> genericity and inheritance is one of the reasons why Bertrand> some of the biggest successful industrial O-O projects Bertrand> have been produced in Eiffel. When the goal is not just Bertrand> to play around, but to build large, mission-critical Bertrand> systems, one needs the right combination of mechanisms, Bertrand> not just a partial attempt. Bertrand> For details about the Eiffel mechanism see the Eiffel Bertrand> language tutorial at http://www.eiffel.com. Bertrand> -- Bertrand Meyer, President, ISE Inc., Santa Barbara Bertrand> (California) 805-685-1006, fax 805-685-6869, Bertrand> - ftp://ftp.eiffel.com Visit our Bertrand> Web page: http://www.eiffel.com (WITH FRAMES) or Bertrand> http://www.eiffel.com/noframes.html Markus -- +----------------------------------------------------------------------------+ | Markus Kohler Hewlett-Packard GmbH | | Software Engineer Network & System Management Division| | IT/E Success Team | +----------------------------------------------------------------------------+