defender methods and method of Object

[Neal Gafter]

This would violate a very valuable design principle: As a rule, annotations
should not affect the behavior of running the annotated code (except to the
extent that it may affect the behavior through APIs that look at the
annotations).

On Fri, Mar 9, 2012 at 2:29 PM, Gregg Wonderly <gregg at wonderly.org> wrote:

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