Allow default methods to override Object's methods

[Stephen Colebourne]

FWIW, this bothered me in JSR310 and still feels wrong in my gut. I've read
and understood the rationale, but think that these three are going to want
to be commonly defined by an interface. I also think developers in general
will see the inability to override as mysterious or a bug.
Stephen

On 1 Mar 2013 01:35, "Howard Lovatt" <howard.lovatt at gmail.com> wrote:
>
> Playing round with the lambdas is generally going well for me, good fun.
>
> However a couple of times I have wanted to override Object's methods, i.e.
> toString, equals, and hashCode. For example in a toy stream library I am
> playing with:
>
> @FunctionalInterface public interface IntStream {
>   int next() throws Break, Continue;
>
>   default void forEach(final IntConsumer consumer) {
>     try {
>       for (;;) {
>         try { consumer.accept(next()); }
>         catch (final Continue notUsed) {}
>       }
>     }
>     catch (final Break notUsed) {}
>   }
>
>   default IntStream map(final IntUnaryOperator unary) { return () ->
> unary.applyAsInt(next()); }
> }
>
> It would be great to override toString, equals, and hashCode just like a
> List does.
>
> I think this has been discussed before I don't remember anyone having any
> examples of were it would be useful.
>
> Do you think the above is a genuine example or an outlying case?
>
>   -- Howard.
>