defender methods and method of Object

[Gregg Wonderly]

I am thinking specifically of visibility controls that might act like final does in terms of allowing overriding definition.

Gregg

On Mar 9, 2012, at 4:51 PM, Neal Gafter <neal at gafter.com> wrote:

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