Re: Announce: The Ultimate SI Units Cracker

[Wes Groleau <wesgroleau@despammed.com>]

> > What I'm getting at is the ability to define a private type
> > so that it has all the attributes and operations of a numeric
> > type and can be use as a generic parameter to a numeric package.
> 
> That would be really cool, perhaps with some Ada0Y features...
> But then it's not clear what e.g. a generic should do with the non-numeric
> components. It could just ignore them. But then how should a function know what
> to return if the actual for the formal T is SI_Unit?
> 
> generic
>   type T is digits <>;
> function F (X, Y: T) return T;

This means that the generic body can expect T to have
all the operations that any floating point type has.
It can not expect it to have any operations that are
not common to all floating point types.

The function would have to return whatever the generic
actual is.  And it can only get that by operations that
are inherited or overridden from Float or that it defines
by using such operations.

MAYBE ....

type Clever is private digits 9;

private

   type Clever is ....

end;

Require the body to define ALL operations
that would be available for a true floating
point type.  I know this is difficult--that's
probably why Java chose to have its dichotomy
between primitive types that are actually numbers,
and object-oriented types which, no matter how hard
you try, you _can't_ treat completely as numbers.

Or can you?

If some Java files have

class myInteger extends Integer
{
   ....
}

and

   myInteger WeeksInYear = new myInteger ( 52 );
   myInteger DaysInWeek  = new myInteger (  7 );

does Java allow methods to be defined to support

     myInteger DaysInYear  = WeeksInYear * DaysInWeek + 1;

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau