Method References

[Reinier Zwitserloot]

Is this really necessary? If the signature of saveState is:

void saveState() {
    ...
}

then instead of adding syntax so you can write:

#void() saveStateRef = this#saveState;

you can just use the existing closures status quo:

#void() saveStateRef = #() {saveState();};

The syntax gets more wordy when there are a lot of parameters, and you have
to switch from brackets to parens depending on whether the method you're
trying to turn into a closure returns void or non-void, and this is clearly
inferior to just being able to write "this#saveState", but, two things:

 1. Methods aren't closures. They are similar, but with the explicit 'call
it in a closure' style, you make this more obvious.

 2. The second way means zero additional effort required in the JLS and
compiler; you get it for free with closure support.

Perhaps said differently, if the closure syntax CANNOT effortlessly wrap
around methods, maybe the closure syntax (whatever it ends up being) is no
good.

--Reinier Zwitserloot

On Fri, Feb 26, 2010 at 5:40 PM, Joshua Bloch <jjb at google.com> wrote:

> I agree that method references would be a fine addition to the proposal,
> and
> I like the proposed syntax. I believe it's important that method references
> work for constructors and static methods as well as instance methods.
>
> I am very much in favor of allowing the user to omit the type information
> when it's unambiguous.  In fact, is their any reason to use "this" (as
> proposed by Fredrick):
>
>    cb = this#saveState;
>
> or could we allow:
>
>    cb = #saveState;
>
> 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.
> >
> >
>
>