Common Super Type for Boxed Types and Array Types

[Brian Goetz]

Modeling numerics with real programming languages is hard, and any given 
language's attempt will surely have something to hate.  (Computer 
numbers are not like math numbers; the integers form a well-ordered 
field, but computer integers do not respect things like "if a > 0, then 
a+b > b".)

Your particular proposal falls down in that a Number need not be a 
Primitive Box; what about BigInteger?  (Now that we have sealed types, 
it would be possible to introduce a sealed _interface_ for the eight box 
types, but that would not be practical until sealed types exits preview.)

The array types are a bigger problem, but because the array types are 
built into the JVM rather than classfiles generated by the java 
compiler, retrofitting new supertypes is several orders of magnitude 
more expensive.  And a far bigger problem is the lack of array 
covariance; that while Integer[] is a subtype of Object[], int[] is 
not.  This means that a supertype like `ArrayPrimitive<T>` is not as 
useful as it looks, as there is no common supertype (other than Object) 
to erase to.

Bottom line: this is all a lot more complicated than it looks.

Cheers,
-Brian

On 12/10/2020 4:00 AM, Suminda Sirinath Salpitikorala Dharmasena wrote:
> Hello,
>
> Some of the boxed types device directly from Object. Also, the array types
> derive from Object.
>
> This is sometimes inconvenient when pacifying API signatures and bounds.
>
> So is it possible to consider a hierarchy like:
> - BoxedPrimitive
>    - Number
>      - Integer
>      - ...
>    - Boolean
>    - Character
> - Array
>    - PrimitiveArray
>      - NumberArray
>        - int[]
>        - ...
>    - boolean[]
>    - character[]
>    - ObjectArray<T>
>
> Suminda