AbstractList etc. functionality as interfaces with default methods?

[Vitaly Davidovich]

That's an implementation detail not a fundamental issue right?

sent from my phone
On May 14, 2015 10:04 AM, "Brian Goetz" <brian.goetz at oracle.com> wrote:

> The static-instance asymmetry cancels that one out.  If you have
>
> class Foo {
>     void m(int x)
>     static void m(Foo f, int x)
> }
>
> Then Foo::x could either be an unbound mref to the instance method or a
> static mref.  Even with a perfect target type (Foo, int) -> void, compiler
> will still report ambiguity.
>
> On May 14, 2015, at 9:52 AM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>
> > Ambiguous in isolation, but within context they're quite different: one
> > takes an arg and the other is void.
> >
> > sent from my phone
> > On May 14, 2015 9:25 AM, "Remi Forax" <forax at univ-mlv.fr> wrote:
> >
> >>
> >>
> >> On 05/14/2015 03:05 PM, Brian Goetz wrote:
> >>
> >>> Not only is there a problem with modCount, but also with
> >>>>> equals/hashCode/toString.  You can’t define these Object methods in
> an
> >>>>> interface.
> >>>>>
> >>>> They could be defined as static methods to delegate to. From API
> >>>> consistency perspective, we have for example the following static
> methods
> >>>> on primitive wrapper classes:
> >>>>
> >>> Right.  We considered this during Lambda, but by the time we got here,
> we
> >>> concluded that this was mostly trading one downside for another.  It
> seemed
> >>> overwhelmingly likely that people would forget to override
> >>> equals/hashCode/toString in this case, and create collections that
> violated
> >>> the contract.
> >>>
> >>>
> >> The other problem is that it creates ambiguous method references,
> >> if you have a class or an interface like:
> >> class A {
> >>  public static int hashCode(A a) { ... }
> >> }
> >>
> >> A::hashCode is ambiguous.
> >>
> >> cheers,
> >> Rémi
> >>
> >>
>
>