Method References

[Neal Gafter]

Fredrik-

I agree.  The ambiguity between the receiver being bound and the
receiver being unbound in a method reference is the reason we had made
the receiver explicit.  This issue doesn't arise with ordinary method
invocations, because in that case it is impossible to have the
receiver unbound.

It isn't easy to make the shorthand "default" to one or another
behavior either.  In a static context only the unbound method
reference makes sense, but in a nonstatic context both are possible.

Cheers,
Neal

On Fri, Feb 26, 2010 at 11:26 AM, Fredrik Öhrström
<fredrik.ohrstrom at oracle.com> wrote:
> Joshua Bloch wrote:
>> or could we allow:
>>
>>     cb = #saveState;
>>
>>
> When you bind a callback to your own code in the constructur, then you want
> to use
>  my_button.onClick(this#saveState);
>
> When you bind a callback between two objects that you have created then you
> want to use:
>  model.onChange(view#notify);
>
> Sometimes you are interested in acquiring a function that encapsulates
> the virtual dispatch
> of a particular message (ie method name). I call this a "stored
> message". This could be
> acquired using:
>  MyApp#saveState
> and would be equivalent to the lamda:
>  #(MyApp a) a.saveState()
>
> You might also want to refer to the static function:
>  MyApp#staticSaveState
>
> So, should #saveState  be:
>  1) this#saveState
>  2) MyApp#saveState
>  3) MyApp#saveState that is static
>  4) Not allowed at all.
>
> I would like the following three expressions to be identical (sed
> s/invoke//g if you like that better, I don't):
>
> reziver.message();
> (#message).invoke(reziver);
> (reziver#message).invoke();
>
>  From this follows that #saveState will give you a stored message if
> saveState uniquely identifies a method in the enclosing class. If
> #saveState uniquely identifies a static function, then it will be that
> static function.
>
> //Fredrik
>
>> Not only is this more succinct, but it mirrors the rules for method
>> invocation, allowing "reasoning by analogy" and reducing programmer
>> astonishment.
>>
>>             Josh
>>
>> On Fri, Feb 26, 2010 at 8:15 AM, Neal Gafter <neal at gafter.com> wrote:
>>
>>
>>> On Fri, Feb 26, 2010 at 2:45 AM, Rémi Forax <forax at univ-mlv.fr> wrote:
>>>
>>>
>>>> there is a source compatibility issue if you allow to not specify the
>>>>
>>> type.
>>>
>>>> class A {
>>>>   void m(String s) { ... }
>>>> }
>>>> ....
>>>> ref = A#m;
>>>>
>>>> Now suppose I want to add a new method m(Integer),
>>>>
>>>>
>>> Adding a new method to a class is not a source-compatible change today.
>>>  However, it is a binary-compatible change today and both with and without
>>> method references and with or without the proposed method reference
>>> argument
>>> inference.
>>>
>>>
>>>
>>
>>
>
>
>