Numeric

[Doug Lea]

On 09/17/12 01:45, Joe Darcy wrote:

> One quick observation on this API, the bound "PreferredType extends Number" does
> not limit the preferred value to one of the boxed primitives java.lang.{Integer,
> Long, Double, ...}

Yes. The main downside is that Numeric is not perfect for
someday guiding/automating future primitive specializations.
The addition of method getNumber (a variant of one of Brian's
suggestions) helps a bit...

public interface Numeric<PreferredType extends Number> {
     long getLong();
     int getInt();
     short getShort();
     byte getByte();
     double getDouble();
     float getFloat();
     PreferredType getNumber();
}

... because then it becomes easier for compilers/VMS to
possible specially handle only those with a PreferredType
corresponding to boxed types. But in any case, people can use
Numeric in cases where no primitive specialization
is even possible, so at best it is a guide.

Still, I think that the main question here is whether, in
the absence of language/VM supported specialization, the
benefits of using Numeric to reduce interface/class/method
combinatorics (as well as to reduce boxing) are worthwhile.
It's too bad that it is only a partial solution.
It would be nicer to find a scheme such that for each
relevant collection, stream, etc you needed only a
"plain" and a "Numeric" version. (Although looking further
ahead, introducing compound value/tuple types may
complicate this.)

-Doug