Re: Is ADA as good for graphics programming as C? (WAS: Re: Avoiding the second historic mistake)

[jsa@alexandria.organon.com (Jon S Anthony)]

In article <EDAsu7.MLn@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

> I think what Nick means is that because Ada does not define Integer
> and Float as classes inheriting from a common ancestor class
> Numeric, they are less

Who cares.  In typical practice this is not even going to be used -
the efficiency sucks for any real numerical work and you will have to
resort to expanded types anyway.


> flexible than in Eiffel. In particular, you can't declare a generic
> Numeric container class and constrain *through inheritance* to store
> Integers or Floats.  Consequently, you can't use a Numeric container
> polymorphically by substituting an Integer or Float container. Also,
> you can't store both Floats and Integers in the same Numeric
> container. These things are simple and straightforward to do in
> Eiffel because INTEGER and REAL are both classes (as well as types)
> inheriting from class NUMERIC.

Shrug.  If you want that, just build Numeric.  But really, I doubt
that this is something you will want in the sort of applications Ada
and Eiffel target.  You want this sort of stuff?  Use CL.


> In Ada, there is something like a notional Numeric *type* having
> properties like assignment and addition but because it is not a
> class (tagged type), it's not extensible through inheritance. You

False.  You can extend and change the _behavior_ through inheritance.


> *other* inheritance mechanism - derived types - but that doesn't allow 
> polymorphism so you miss something compared with Eiffel.

Right.  As for polymorphism here - again who cares? as it is not very
likely that you want dispatching on individual numbers anyway.


> :Examples (*) and (**) are examples of "constrained genericity," which is
> :exactly what you said would be really nice to have.  So you have it an
> :Eiffel AND Ada.
> 
> No, I think Nick meant constraining from a common ancestor *through 
> inheritance*

OK, but again - who cares?  IMO, forcing everything into a
classification style of model naive, simplistic, overly constraining,
and typically wrong.


> :In Ada, you can even do mixin inheritance without using multiple
> :inheritance.  
> 
> Yes, through a round-about way using genericity. This is inelegant compared 
> with multiple inheritance.

No it is not.  IMO, for mixins, the generic + SI is a _much_ better
model as it does not confuse the issue with any sort of is-a
semantics.  Just because I want to mixin a printing capability with my
rational number facility, does not mean that my rational numbers
suddenly become printers, but with MI, that is basically what you are
saying even though you probably don't mean it.  What you are really
looking for with mixins is composition with a form of automatic
delegation.


> However, it's simple compared to the obscure technique for acheiving
> multiple views in Ada95 Rationale, Section 4.6.3.  I'm still trying
> to comprehend that one!

It is obscure, but not particularly difficult.  However, I agree that
is the one case where MI is actually useful.  OTOH, this is relatively
rare thing.  IMO, if you really want/need this level of capability,
then you may as well just use CLOS, as it is far more capable than
either Ada's or Eiffel's object model.


/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178
617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari