defender methods and method of Object

[Yuval Shavit]

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
>
>