Wither method references?

Talden talden at gmail.com
Tue Jun 21 17:57:48 PDT 2011


On Tue, Jun 21, 2011 at 9:22 PM, Reinier Zwitserloot
<reinier at zwitserloot.com> wrote:
> Are method references still in? i.e. something like:
>
> public static int foo(String a, String b) {
>    return a.length() - b.length();
> }
>
> public void whatever() {
>    Comparator<String> x = #foo;
> }
>
>
>
> If so, any dislike of '#' is basically a moot point. # will be in java7
> anyway.
>
> Then a big disadvantage of BGGA or pretty much any non-strawman syntax is
> that it takes out both # and ->, whereas strawman only takes out # for
> language features. The fact that lambda is happening at all suggests its
> useful to have some unused symbols left over for future features :)

Confirmed in a June 14 post from Brian Goetz

On 06/14/2011 01:02 AM, Brian Goetz wrote:
> ... method references are
> still on the list....
>
> The plan as it currently stands:
>    - Lambda expressions
>    - SAM conversion
>    - Type inference of lambda formals
>    - Four kinds of method references (static, instance, unbound instance,
> constructor)
>    - Extension/Defender methods
>    - New methods on collections for map/reduce/forEach/etc

Given that method references convert to SAMs in the same manner as
lambda it seems clearer to me when they share the same symbol.

Additionally I think strawman has a more natural (read, more
java-like) formatting for non-trivial lambdas.  Looking at our
code-base we were something like 1/3 no-arg, 1/3 1 arg, 1/3 2-3 args,
trivial numbers of >3 args (8 being the worst).  It was pretty much
50:50 on whether they could be written as single
expressions/statements or blocks - more lambda using APIs in the Java
SE classes would increase the former more than the latter I would
expect.

BigLongGenerifiedSamDeclaration foo =
  #(a, b, c) {
    ...
  };

thatObject.apply(
  #(a, b, c) {
    ...
  });

thisObject.apply(#(x) { x + 1 });

anotherObject.apply(#{ justDoIt() });

vs

BigLongGenerifiedSamDeclaration foo =
  {a, b, c ->
    ...
  };

thatObject.apply(
  {a, b, c ->
    ...
  });

thisObject.apply({ x -> x + 1 });

anotherObject.apply({ -> justDoIt() });


I can live with BGGA (or a version with a preceding #) but the more I
play with lambda in our real code-bases the more I am getting
comfortable with the look of strawman in amongst other java code.
Certainly our complete lambda newbs seem to consume that more easily
(I'm running out of newbs I can spring 'first-glance' feedback surveys
on though). Those with wider language experience seem happier with
BGGA but I don't believe any have really examined it amongst a more
substantial body of code than the examples I've shown them.

The argument for keeping symbols available for the future applies to
the use of 'return' as a return from lambda.  If break/continue/return
are kept available then control abstraction becomes possible without
having two lambda body notations (though you could argue the CA
application of a lambda body has enough context to treat return
differently in that circumstance - it's still an avoidable educational
hurdle).

--
Aaron Scott-Boddendijk


More information about the lambda-dev mailing list