Reference implementation

Jonathan Gibbons Jonathan.Gibbons at Sun.COM
Wed Oct 28 13:41:35 PDT 2009


Neal Gafter wrote:
> On Wed, Oct 28, 2009 at 10:56 AM, Maurizio Cimadamore <
> Maurizio.Cimadamore at sun.com> wrote:
>
>   
>> Neal Gafter wrote:
>>
>>     
>>> Maurizio-
>>>
>>> Here's my concern: Quoting from
>>> http://mail.openjdk.java.net/pipermail/coin-dev/2009-August/002165.html,
>>> inference proceeds in two steps, in this order:
>>>
>>>   1. inference from actual vs. formal arguments (see JLS 15.12.2.7)
>>>   2. inference from return type vs. expected type (see JLS 15.12.2.8)
>>>
>>>
>>> For consistency, any future extension of inference to argument contexts
>>> should also proceed in this order - in fact, must proceed in this order
>>> because overload resolution depends on the results of the first step, and
>>> the results of overload resolution are required to apply the second step.
>>>
>>>       
>> Hi Neal
>> When you say that overload resolution depends on the result of the first
>> step, I guess you refer to the fact that both 15.12.2.2, 15.12.2.3 and
>> 15.12.2.4 refer to 15.12.2.7. Well this is not much of a concern - that
>> inference step can be replaced by a full-inference step (round 1 followed by
>> round 2) where the expected type is unspecified.
>>
>>     
>
> Isn't that basically what is done today?  That is, the parameter type is
> ignored ("unspecified") when performing type inference on a method
> invocation in an argument context.  That is exactly the issue I'm hoping
> will be fixed in a future extension: the method's (expected) parameter type
> *should* play a part in the second phase.
>
> Moreover, we think that it is very important to be able to refactor code
>   
>> like:
>>
>> class Foo<X> {
>>   Foo(X x) {...}
>> }
>>
>> Foo<Object> fo = new Foo<Object>(1);
>>
>> with your proposed approach the above code will give an error (see
>> statistics and results in [1]).
>>     
>
>
> I see that you conclude, based on those statistics, that "No approach looks
> noticeably better than the other."  Your main reason for preferring the
> simple approach appears to be that inference in argument positions isn't
> done, so few benefits accrue to the more complex approach.  However, I would
> hope that consideration of future language evolution - that is, argument
> inference might be desirable *in the future* - to be a deciding factor.
>
> Cheers,
> Neal
>
>   
Neal,

In the short term, we think that the current ("simple") approach is the 
way to go. Long term, we think we will need something like the 
"full-complex" approach that Maurizio has described. That will address 
the need for argument inference. However, we do not have the resources 
to fully investigate that solution at this point.

-- Jon



More information about the coin-dev mailing list