AbstractList etc. functionality as interfaces with default methods?

[Vitaly Davidovich]

That's fine, not complaining, but as you say, it was a conscious design
decision; alternative syntax could have been used to not make this
ambiguous.  Given that APIs try to be lean and only support minimal
required functionality, "extensions" are bolted on via static helper
methods, so having a way to avoid this ambiguity would've been nice.  But
not a big deal, we can just name things differently then :)

On Thu, May 14, 2015 at 10:27 AM, Brian Goetz <brian.goetz at oracle.com>
wrote:

> No, it’s fundamental, and it was a conscious trade-off.  The uniformity of
> using the same syntax for all flavors of method references outweighed the
> small number of collisions like this one.
>
> On May 14, 2015, at 10:06 AM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>
> 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
>> >>
>> >>
>>
>>
>