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