Transparancy
Mikael Grev
grev at miginfocom.com
Thu Jul 8 14:59:36 PDT 2010
I actually don't find return in F very strange. It works for me.
In the perfect world you can always make the decisions on pure technical merits and all will follow and accept. What I mean is that there is a tradeoff here.
People will hate the yield keyword simply because so few will understand the IMO very little benefit of holding the return keyword for, again IMO, a bad future possibility. You fare a big risk of being nuked in the blogosphere and that means more than any technical merits it may have. Think generics here, how may understand why they are as they are, yet they love to hate them? I think many will mean that if you add a keywords that easily why not for other things? Sun has been really reluctant to add keywords before, for better reasons ("property" comes to mind).
Well, I don't think we will get any further in this thread. Make a decision and move on. :)
Cheers,
Mikael
On Jul 8, 2010, at 19:20 PM, Brian Goetz wrote:
>> Most developers seem to think that a lambda body is comparable to a SAM/AIC implementation body, which is a method.
>
> This is true, but only because they have no other experience. The reality is that they are mostly like method bodies, but not entirely like method bodies. Such first-order approximations are very useful in forming mental models but should not be taken too far!
>
> Here are some contexts in Java-like languages where a control flow statement stops executing in the current context and resumes in another:
>
> A Return from a method.
> B Local return from a closure.
> C Lexical return from a closure.
> D Incremental production from a coroutine.
> E Terminal production from a coroutine.
> F Value production from a local block (i.e.:
> var x = { var y = 3; yield 3*y }
> G Lexical return from a local block.
>
> Java currently only has A. So our thinking about "what return means" is heavily conditioned by our experience with A.
>
> BGGA has both B and C. The current SotL draft has "yield" for B and currently nothing for "C".
>
> I think we can all agree that "return" is absurd for "F". (You might not like "yield" because it is used for something else (D/E) in C# and yet something else (and weird!) in Ruby, but "yield" is a fine candidate for F.)
>
> So "return" is obviously right for A and obviously wrong for F. B and C have something in common with methods, and something in common with local blocks. We're letting the fact that Java has methods and does not have local blocks color our thinking that closures are "just like" methods when in fact they are "mostly like" methods. (We can disagree about whether it's 98/2 or 90/10, but it's obviously not 100/0.)
>
> Imagine you grew up in a world where the only animals were dogs (methods). Your mental model of animal would be heavily influenced by the characteristics of dogs -- for example, animals have four legs*. Then one day ants (local blocks) were introduced into your planet. They are obviously not dogs, but they have more legs than you and are shorter than you, so they are more like dogs than like humans, so we redefine the world as "there are people and animals; animals are dogs and ants." Having thus classified things, you are again comfortable with the world. Two hundred years later, a cat (closure) arrives on your planet. Most people in this situation will think "what a fancy dog!"
>
> The point is that "return" is only obvious for B if you have grown up in the world of A-but-not-F. And if we're sure that C/D/E/F/G will *never* be added to Java, then we are perfectly justified in ignoring all the cat-like aspects of closures and lump them in with dogs, and choose "return" for B and never think about it again. But if there's any reasonable chance that F (or even C) will ever become part of Java, then all of a sudden these dogs that say "meow" start to seem really weird.
>
> That said, this forum is for lambda discussions, so this is probably not the place for a discussion about which of these forms Java should have (beyond A/B/C). However, considerations of where Java might or might not go in future releases that do not even have numbers yet do (and should!) inform our thoughts.
>
>
>
>
> *Yes, everyone has a three-legged dog story.
More information about the lambda-dev
mailing list