defender methods and method of Object

[Yuval Shavit]

On Mon, Mar 12, 2012 at 11:02 AM, Brian Goetz <brian.goetz at oracle.com>wrote:

> > On the other hand, for those use cases where it does make sense to
> provide
> > implementations (on collection classes, as several people have pointed
> > out), it will not even be possible to do so unless steps are taken to
> > enable it.
>
> You can easily provide these methods in List as a favor to implementation
> classes.  For example, if List provided the equals and hashCode methods, a
> class could then easily choose to inherit them:
>
>  int hashCode() { return List.super.hashCode(); }
>
> without the class having to code them up by hand.  It is not as unwieldy
> as you make it sound.
>
> In any case, I think you have the sense of the burden backwards.  The bar
> is not "we should add special cases if anyone can imagine how they could be
> useful."  The bar is that the special case has to be overwhelmingly
> compelling.  I don't see it here.
>

I think there's two ways to look at it. One is from the perspective of the
spec / java implementation / developer-who-quotes-JLS, and from that
perspective, special-casing Object methods would obviously be, well, a
special case. But the other perspective is from that of the everyday
developer -- the one for whom the principle of least surprise holds -- and
from that perspective, *not* special-casing Object actually seems like the
special case. From that perspective, the rule feels like "a default method
on an interface applies unless a base class provides an implementation, or
unless the method overrides a method on Object." Of course, you can point
out that since Object is always a base class, the "or unless..." part is
implied by the "base class" part -- but it still feels, intuitively, like a
special case.

For instance, taking your List.super.hashCode() example, I could see
how-tos explaining about defender methods and having a subsection called
"Providing a default implementation for Object methods" telling people that
they have to use the above pattern in each implementation (or in some
abstract base class, if one exists). From the perspective of someone
reading such a document, it certainly sounds like a special case -- and one
that requires boilerplate code to fix.