Are function types a requirement?

[Reinier Zwitserloot]

Well, you could get around that by stating that primitives aren't generified
_unless_ a primitive type is used to fulfill a type variable. Thus, in
something like:

public class Test extends ArrayList<int> {
    public int indexOf(int value) { ... }
}

the 'int' in 'int value' is being used to fulfill the generics bound, so
it's considered to be "Integer" instead. Of course, that would be very weird
indeed when code is working directly with Test, so it should ALSO stand for
int, which means that's actually 2 methods - indexOf(Integer value) as well
as indexOf(int value). Even if this duality concerns the return type this is
possible (this is already done when tightening the return type in a subclass
- javac generates 2 methods, one of which is a wrapper to the other). of
course, if you have something like:

public T foo(T param1, T param2, T param3, T param4, ...) {}

the permutations required would be bordering on the silly, so this is where
integrating primitives into the generics type system becomes quite
complicated, and you'll need to take shortcuts, such as: Only 1 version with
all-primitives, and one version with all-wrappers is generated (and marked
as synthetic, or some simile thereof to tell IDEs and other code viewing
tools not to list that method).

An alternative is that there really is only int indexOf(Integer x), with
method resolution taking care (via autoboxing) of the rest, but this would
result in some weirdness when viewing the class in for example an IDE
auto-complete dialog; you'd see int indexOf(Integer) even though you wrote
int indexOf(int)!

With such a system f(int) and f(double) will always remain distinct -
there's no way to have a supertype that's got f(T) and f(V) defined in such
a way that this is itself legal (T and V would have to erase to different
base types) but trying to implement them with primitive types would lead to
a signature collision.




--Reinier Zwitserloot



On Thu, Feb 18, 2010 at 9:47 AM, Mark Thornton <mthornton at optrak.co.uk>wrote:

> Reinier Zwitserloot wrote:
>
>> How to allow primitives in generics declarations has been researched, and
>> abandoned, before, but if we can solve this problem today then function
>> types can be dropped. The cost/value analysis of trying to make it work
>> has
>> perhaps changed now - simplying closures considerably is now added to the
>> value.
>>
>> ...
>>
>>
>> If anyone remembers or has a link to the problems inherent in allowing
>> primitives in generics, that would be useful for this discussion.
>>
>>
> I found it difficult to do consistently without also reifying generics. You
> have to reify the primitives so that f(int) is distinct from f(double). Then
> you really want to reify the rest as well. At least that is my amateur take
> on it.
>
> Mark Thornton
>
>
>