AbstractList etc. functionality as interfaces with default methods? (original) (raw)

Vitaly Davidovich vitalyd at gmail.com
Thu May 14 14:06:46 UTC 2015

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 >> >>

More information about the core-libs-dev mailing list