We should consider breaking out of a closure using some language syntax.
At the implementation level it could be that 'break' really just throws a ClosureBreakException which the each() method could catch to terminate the loop.
Isn't this kind of like a coroutine where the each() defines "break" and "continue" operations and the closure can choose to activate those operations.
We could define some basic conventions that all groovy iteration methods would support – "break" and "continue" would be pretty standard, but I can see where you may want to start defining your own entry points that subclosures could continue on.
Hope this makes sense.
There's a further discussion of this at http://docs.codehaus.org/display/GroovyJSR/closure+syntax
In order to be compatible with Java, an unlabeled 'break' should have a specific meaning drawn from Java. (Principle of least surprise.)
However, a labeled 'break' works in an unsurprising way:
For a concise common use-case, we should also say that a block appended to a method call is implicitly labeled by the name of the method:
A 'continue' (labeled or not) can be transformed into a 'break' of the loop body, not the loop as a whole. Therefore, 'continue' can be treated as syntax sugar on top of 'break'. The details are straightforward.
Finally, if we let statements have values (which I support), 'break' and 'continue' need to be able to take an optional expression argument, as in break find: "found it".
break find: "found it"
Powered by a free Atlassian Confluence Open Source Project License granted to Codehaus. Evaluate Confluence today.