defender methods and method of Object

[Gregg Wonderly]

Annotations might be useful to let developers tell the compiler more about what 
is desirable.  I am not sure that anything makes it perfect, but if there are 
specific , useful behaviors, which are in conflict, then letting developers 
state what specific behavior they want, might provide a reasonable compromise.

Gregg Wonderly

On 3/9/2012 3:45 PM, Yuval Shavit wrote:
> Well, toString also makes sense for collections, and I was taught to try
> very hard to avoid the other two anyway.
>
> On Fri, Mar 9, 2012 at 3:17 PM, David M. Lloyd<david.lloyd at redhat.com>wrote:
>
>> I agree on this much (allowing default equals/hashCode methods).
>> However I think that other methods (namely toString, and clone and
>> finalize for that matter) should definitely not ever be specified on an
>> interface.  I'm not sure there's a good technical solution to this
>> conundrum though.
>>
>> On 03/09/2012 01:59 PM, Dan Smith wrote:
>>> Well, see java.util.List.equals, and the corresponding implementation
>> java.util.AbstractList.equals.  If we had default methods before
>> AbstractList was defined, it (or much of it) would probably have ended up
>> in the List interface, including 'equals'.
>>> —Dan
>>>
>>> On Mar 9, 2012, at 11:23 AM, Brian Goetz wrote:
>>>
>>>> I'm not convinced.  The implementations of equals, hashCode, and
>> toString provided by an interface are almost certainly going to be wrong
>> for most subclasses that inherit them, whereas the versions provided by
>> Object are generally sound, if basic.  (To say nothing of the pain that
>> will ensue when someone adds a hashCode/equals method pair to an interface
>> implemented by a class that doesn't provide such a pair (which is a
>> reasonable choice), and all of a sudden, behavior of that class when put
>> into hash-based containers changes wildly.)
>>>>
>>>> On 3/9/2012 12:56 PM, Dan Smith wrote:
>>>>> Yes, I've been thinking the same thing.  Since the Object methods are
>> morally members of every interface, it would make sense that a default
>> method could effectively override them, and the "throw out all super
>> methods that have already been overridden" rule could then apply.  It all
>> depends on what order the inheritance conflict-resolution rules are applied
>> in.
>>>>> (There's something to the argument in the other direction, though,
>> that it's really nice that if a method is implemented in the class
>> hierarchy, we ignore the interfaces.  It seems like the implementation
>> relies on this pretty heavily, and it could get hairy if every single class
>> had the potential of inherited default methods replacing the behavior of
>> Object methods.)
>>>>> —Dan
>>>>>
>>>>> On Mar 3, 2012, at 12:45 PM, Sam Pullara wrote:
>>>>>
>>>>>> I am all for special casing these. It is far too useful to be able to
>>>>>> provide equals()/hashCode()/toString() at the interface level for
>>>>>> things like List to not to include this capability. Especially since
>>>>>> there is precedent for their special treatment.
>>>>>>
>>>>>> Sam
>>>>>>
>>>>>> On Sat, Mar 3, 2012 at 11:19 AM, Yuval Shavit<yshavit at akiban.com>
>> wrote:
>>>>>>> Well, Object is special-cased in the very definition of an interface
>> (in
>>>>>>> 4.10.2), so I could see the case for special-casing it for default
>>>>>>> implementations.
>>>>>>>
>>>>>>> On Sat, Mar 3, 2012 at 6:23 AM, David Holmes<david.holmes at oracle.com
>>> wrote:
>>>>>>>> I don't see any reason to special case Object methods. Superclass
>> wins
>>>>>>>> over interface with a default - pure and simple.
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>> On 3/03/2012 2:19 AM, Rémi Forax wrote:
>>>>>>>>> On 03/02/2012 05:08 PM, bitter_fox wrote:
>>>>>>>>>> Hi,
>>>>>>>>>> You have to override toString in A to use the default
>> implementation,
>>>>>>>>>> in this case, using the syntax "Interface.super.method()":
>>>>>>>>>> (because the definition of super-class is preferred if the
>> extended
>>>>>>>>>> definitions from super-class and super-interface are clashing)
>>>>>>>>>>
>>>>>>>>>> public class A implements Foo
>>>>>>>>>> {
>>>>>>>>>>        public String toString()
>>>>>>>>>>        {
>>>>>>>>>>            return Foo.super.toString();
>>>>>>>>>>        }
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> new A().toString(); // returns "Foo"
>>>>>>>>>>
>>>>>>>>>> However, this calling would be StackOverflowError because the
>> syntax
>>>>>>>>>> may be only on "Syntax" and be not implemented for byte code.
>>>>>>>>>>
>>>>>>>>>> I can't judge that semantics is right or wrong, so I only refer
>> to the
>>>>>>>>>> way to override.(Although I think it is right...)
>>>>>>>>>> Excuse me if you already know the way.
>>>>>>>>> No problem.
>>>>>>>>> I just think that the semantics should be changed a little bit by
>> adding
>>>>>>>>> a special case for method from Object because
>>>>>>>>> otherwise the default method will be never called directly
>>>>>>>>> (as you said, you can use I.super.foo()).
>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> bitter_fox
>>>>>>>>> cheers,
>>>>>>>>> Rémi
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>
>>>
>>
>> --
>> - DML
>>
>>
>