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

[jsa@alexandria (Jon S Anthony)]

In article <32D2E6C8.13728473@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:

Wow.  The big folk are coming out.  Add in a couple others and the
whole thing might start looking like the Vorlons and Shadows! :-)

I'll play a Ranger (representing Ada, of course, ;-)


> 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:

This is not surprising, ;-)

But,

> 	- 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.

This is in Ada95:
generic
    type G is private;
package List 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.

This too is in Ada95:

generic
    type G is new Comparable with private;
package Sorted_List is ...

Same instantiation constraints as in the Eiffel case...


> 	- True static typing (with no cast a la C++).

Yes, this is in Ada95 too.  In fact it is better in Ada95 since it
does not have system validity problems.


> 	- 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.)

OK, here you have me.  But, Eiffel hedges a bit here as well with its
"expanded types".


> So in the constrained genericity case SORTED_LIST [INTEGER]
> will be permitted, since COMPARABLE is indeed an existing class,

Good point.  Lost a Minbari Cruiser on this one...


> 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

Same as in Ada.


> 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.

Here is where you actually get some more flexibility with Ada as you
can parameterize your generic (either the constrained or unconstrained
type) with more than just types.  You can specify complete signatures
including operations and/or packages as well.  What's more, these can
have constraints on them as well.  Of course, it doesn't have real
assertions, so I suppose this is kind of a wash...


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com