What should default interfaces be for?

[Yuval Shavit]

Not that I have much experience with designing language features, but it
seems to me that if defender methods make it into the language, they'll
become a true part of the language -- and they'll be used for more than
just interface evolution, whether we like it or not. So, rather than
discussing whether we like it or not, I wonder if we should be discussing
whether we should *embrace it* or not. More concretely, do we want to say,
"you can do this thing, but we don't want you to, so your code will have
ugly boilerplates," or "you can do this thing."

Personally, I'm far more excited about lambdas than about defender methods
(except insofar as they'll allow interface evolution). But I do think that
once a feature is brought into a language, it should be a first-class
citizen within that language (at least until some other construct replaces
it, as generics did to what we now call raw types).

On Wed, Mar 14, 2012 at 3:00 PM, Richard Warburton <
richard.warburton at gmail.com> wrote:

> > I dislike the idea of allowing implementation inside interfaces, so I
> > see default methods as a necessary evil for interface evolution. And I
> > fully agree with the view that developers should not implicitly depend
> > on default methods. Even more: why not let the Java compiler emit a
> > warning when classes do depend on default methods?
> >
> > PS: in case it wouldn't be clear by now: I 'm against allowing Object
> > methods as default methods :)
>
> Hey,
>
> I think it would be a helpful if you explained your perspective a
> little more.  I'm sure you've undertaken some thought and come up with
> cases where its open to abuse - what are they?  Perhaps you don't like
> the confusion between the method signature specification (an
> interface) and the implementation.  I always think its good to
> understand why you've reached an opinion, rather than simply what that
> opinion is.
>
> regards,
>
>  Richard
>
>