defender methods and method of Object

[Sam Pullara]

I totally agree with Yuval on this. Object methods are a special case
for interfaces and we need to be consistent. I'd like to avoid the
boilerplate.

Sam

On Mon, Mar 12, 2012 at 8:37 AM, Yuval Shavit <yshavit at akiban.com> wrote:
> 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.
>