extension method implementations for methods of java.lang.Object
Thomas Jung
thomas.andreas.jung at googlemail.com
Thu Aug 19 06:12:13 PDT 2010
That's clear. To support this use cases the method resolution rules
would have to be changed (i.e. complicated).
Thomas
On 19 August 2010 15:05, Brian Goetz <brian.goetz at oracle.com> wrote:
> But, even given that, in this case the resolution for a call to equals()
> would go straight to Object.equals(), since we only consult defaults if the
> object does not already have an implementation from its inheritance
> hierarchy. All objects already have an equals().
>
> On 8/19/2010 4:50 AM, Maurizio Cimadamore wrote:
>>
>> On 19/08/10 08:59, Thomas Jung wrote:
>>>
>>> Hi,
>>>
>>> with the current prototype it's not possible to define a default
>>> implementation for Object#equals.
>>>
>>> interface A{
>>> extension boolean xequals(Object obj) default As.eq;
>>> extension boolean equals(Object obj) default As.eq;
>>> }
>>>
>>> static class As{
>>> public static boolean eq(A me, Object object){
>>> throw new RuntimeException();
>>> }
>>> }
>>>
>>> a.equals(new Object()); //passes
>>> a.xequals(new Object()); //throws exception
>>>
>>> This feature is useful if the equals implementation for some subtypes
>>> of A can be expressed based on the methods defined in A.
>>>
>> The VM extension required to handle extension methods at runtime is not
>> available yet - as a result it is not possible to get to execute the
>> above code (or any code containing extension methods) with the right
>> semantics... in fact, since the runtime infrastructure is missing, the
>> VM gets method dispatching completely wrong - the invokevirtual
>> targeting A.equals() is dispatched to Object.equals() while for
>> A.xequals() the VM complains because it cannot find a suitable
>> implementation of xequals() inside the instance 'a'.
>>
>> Maurizio
>>>
>>> -
>>> Thomas
>>>
>>>
>>
>>
>
More information about the lambda-dev
mailing list