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

[Ken Garlington <GarlingtonKE@lmtas.lmco.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.

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, <bertrand@eiffel.com> -
> 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