Function types versus arrays

[Rémi Forax]

Le 18/02/2010 01:47, Joshua Bloch a écrit :
> Neal,
>
> On Wed, Feb 17, 2010 at 3:10 PM, Neal Gafter<neal at gafter.com>  wrote:
>
>    
>> On Wed, Feb 17, 2010 at 2:59 PM, Joshua Bloch<jjb at google.com>  wrote:
>>      
>>> I really don't understand this.  Earlier on, Alex said that we should
>>> refrain from thinking too hard about the implementation at this point,
>>>        
>> and I
>>      
>>> still believe that to be true.  If you could show that some interaction
>>>        
>> of
>>      
>>> the proposed syntax and semantics interacted poorly with the existing
>>>        
>> type
>>      
>>> system, that would be a big problem, but I haven't seen such an argument
>>> that didn't presuppose a particular implementation of function types. I
>>> really do think we should design the best spec (syntax and semantics) and
>>> then see if it's implementable.
>>>        
>> I agree with the process you describe.  I just think we're a couple of
>> steps ahead of you.  Setting aside the precise syntax, there is a
>> specific problematic interaction of the currently proposed semantics
>> with the existing type system, and we're exploring the fallout of that
>> issue.  We don't have to wait for the syntax to be settled to explore
>> the fallout of the semantics issue, and as I pointed out resolving the
>> semantic issue can help guide the syntax.
>>
>>      
> I don't buy this.  All we know is that it requires some effort to implement
> reified function types. We always claimed that the reason that we did
> generics via erasure was migration compatibility, not ease of
> implementation. *We don't have that excuse this time.*
>
>    
>>      
>>> Earlier, I suggested that we should allow arrays of function types if we
>>> can.  \Otherwise, we're damning function types to life as second-class
>>> citizens of the Java type system. We're also screwing up variable-arity
>>> function typed args, as varargs is a leaky abstraction built atop arrays.
>>>   This isn't a theoretical concern; it impacts reasonable programs. For
>>> example, consider a method that takes a bunch of #int(int) functions and
>>> returns their composition:
>>>      #int(int) compose(#int(int)... fns) {<implementation>  }
>>> This should definitely be legal, and shouldn't generate a warning
>>> (especially given that we're providing a means to eliminate this sort of
>>> warning on generic varargs parameters in Java 7).
>>>        
>> This is all true, but the facts of the universe we live in have
>> conspired against us.  We should if we can, but we can't.
>>      
>
> Can't is a strong word.  All we can say is that it would involve VM change.
>   It may be worth that.
>    

Generics are not reified but you can create a function type
using a type variable or a  parameterized type.
So even if we have fully refied function type, we also need
fully reified generics.

So yes we can .... we "just" have to reified generics.

[...]

>        Josh
>    

Rémi