On Fri, Jul 27, 2012 at 10:16 AM, Ricky Clarkson
<[email protected]> wrote:
> Like I said, without a => there's no closure.
>
> The for comprehension works because it gets converted into code containing a
> =>.
These two sentences don't make sense together. Either you have to
provide the => or you don't. That one will be implied for you goes
against what you are saying. In fact, I think the confusing thing
here is that the "closure" in the first section is a function from
unit to whatever the closure returns. It seems the compiler works
with you by converting that to what the closure returns through
evaluation. (I am more than willing to admit I'm likely wrong here.)
> A block in a position where a function is expected is just a block whose
> value needs to be a function. Does that make sense now? I can probably
> find some specspeak that explains it better if not.
This doesn't make sense because this only worked since you have it
return a function that can work there. Specifically, the unapplied
println. That is, this didn't work because it was a block where a
function is needed, but because it was a block "returning" a function
that was needed. Something a block doesn't do. (return, that is.)
The simple rule of thumb I have is if a new class file gets created to
support a block, then it was a closure. :) Not always obvious from
just looking at the source. Using this guide, you'll find that
changing from:
object Test {
def main(args:Array[String]) {
println("Hello")
}
}
to
object Test {
def main(args:Array[String]) {
1 to 10 map println
}
}
Results in a new classfile generated. For the anonfun that is the
unapplied println.
--
You received this message because you are subscribed to the Google Groups "Java
Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
