Newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!newsstand.cit.cornell.edu!news.tc.cornell.edu!news3.cac.psu.edu!news.cse.psu.edu!uwm.edu!spool.mu.edu!munnari.OZ.AU!news.mel.connect.com.au!news.syd.connect.com.au!syd.csa.com.au!news
From: donh@syd.csa.com.au (Don Harrison)
Subject: Re: OO, C++, and something much better!
X-Nntp-Posting-Host: dev50
Message-ID: <E3q536.31D@syd.csa.com.au>
Sender: news@syd.csa.com.au
Reply-To: donh@syd.csa.com.au
Organization: CSC Australia, Sydney
References: <JSA.97Jan8123334@alexandria>
Date: Thu, 9 Jan 1997 04:42:41 GMT
Lines: 92
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:239176 comp.lang.smalltalk:48773 comp.lang.eiffel:17204 comp.lang.ada:55763 comp.object:59550 comp.software-eng:52289

Jon S Anthony writes:

:In article <32D2E6C8.13728473@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:
:
:Wow.  The big folk are coming out. 

:)

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

Yes.

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

Yes. However, I'm not sure whether you lose some of the power of combining 
genericity with inheritance through Ada's module-type distinction. Since 
genericity in Ada is essentially module-based and inheritance is type-based,
I suspect you may lose something here.

:> 	- True static typing (with no cast a la C++).
:
:Yes, this is in Ada95 too.  

No. Ada offers type casting in a couple of ways:

  1) UNCHECKED_CONVERSION and
  2) Address representation clauses (overlays).

Eiffel, by contrast, has no such thing in the standard language. That isn't 
to say it isn't needed for some things (and is why some vendors do provide 
type conversion between basic types and bits, for example). 

I have been trying to think of a safe way of doing this sort of thing but
thus far haven't thought of any. :) 

:In fact it is better in Ada95 since it
:does not have system validity problems.

Perhaps not the same kind of problems. But it's dead easy to write 'system
invalid' Ada which will result in runtime errors. For example, by using the 
value of a parent type where a subrange value is required.

[...]

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

Yes. However, these kinds of formal parameters are only needed in Ada because
it distinguishes between module and type. Eiffel's unification of module and
type obviates the need for them. :)  Eiffel's genericity mechanism is also
simpler because it is a *pure* OOPL compared to hybrid Ada.

:Of course, it doesn't have real
:assertions, so I suppose this is kind of a wash...


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au


