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

[Bertrand Meyer <bertrand@eiffel.com>]

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, <bertrand@eiffel.com> -
ftp://ftp.eiffel.com
Visit our Web page: http://www.eiffel.com (WITH FRAMES)
	or http://www.eiffel.com/noframes.html