Re: OO, C++, and something much better!

[Kohler Markus <kohlerm@betze.bbn.hp.com>]

>>>>> "Bertrand" == Bertrand Meyer <bertrand@eiffel.com> 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> <bertrand@eiffel.com> - 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                   |
+----------------------------------------------------------------------------+