Just a note for anyone interested in the overloading or redefinition of each
method for a type. You can override the iterator() method and this will
influence each, for-each, for-in, spread and as-collection.
________________________________
From: OCsite <o...@ocs.cz>
Sent: Wednesday, December 4, 2024 12:02 PM
To: Groovy_Developers <dev@groovy.apache.org>
Cc: Milles, Eric (TR Technology) <eric.mil...@thomsonreuters.com>
Subject: Re: [EXT] for loops, returns, and other animals
Miles,
On 4. 12. 2024, at 18:21, Milles, Eric (TR Technology) via dev
<dev@groovy.apache.org> wrote:
... Switching to use "y.each { x-> ... }" or "y.forEach(x -> ...)" is a
personal preference.
Absolutely.
Nevertheless my own personal preference very strongly prefers :) the each, for
it is a pure OO approach, including e.g., an easy and intuitive possibility to
implement/override each for any particular target where it might make sense.
(Sort of like the lately debated preference of Foo.newInstance instead of new
Foo.)
(Although I can't recall how offhand, I guess Groovy would most probably be
flexible enough to allow me to override/implement the for/in behaviour for any
class as well, like e.g., Objective C does; nevertheless, even if possible, it
would be far from pure OO and far from intuitive.)
If closure is nested within another closure, is the idea to only support return
from the outermost scope (method)?
Presumed it is intended as a loose equivalent of a return inside a for loop, it
probably should, precisely like return in a nested loop does.
You could experiemnt with Groovy Macro to replace any "expr.each { ... }" with
some other expression. This can typically be done more quickly than an AST
transform. It may not be the final form of your solution, but does let you try
things quickly.
My intention was primarily to open a debate whether such a thing would be worth
to add to Groovy or not, regardless the particular implementation (perhaps I
should not have added the exception-based example at all).
Thanks and all the best,
OC
________________________________
From: OCsite <o...@ocs.cz>
Sent: Wednesday, December 4, 2024 11:03 AM
To: dev@groovy.apache.org <dev@groovy.apache.org>
Subject: [EXT] for loops, returns, and other animals
External Email: Use caution with links and attachments.
MG,
On 4. 12. 2024, at 16:11, MG <mg...@arscreat.com> wrote:
* e.g. using a for(foo : foos) { ... } loop instead of canonical Groovy
foos.each { foo -> ... }, to be able to easily return from the for body from
multiple places using return statements.
For one, I would argue that the native and groovier (since more logical and
intuitive and intention-revealing for anyone who can read English completely
regardless whether he knows Java or not) variant should be the for/in loop,
like for (foo in foos). That weird and unintuitive colon thing should, in my
personal opinion, remain limited to code copy/pasted from Java (exactly like
var :))
That would not be worth an extra email though. I wonder, would it be perhaps
worth the effort to extend the language by adding a support for
method-returning from a closure?
A trivial (and most probably very very wrong and problems-inducing!) approach
might perhaps be an ASTT which would convert code like
def foo() {
bar.each { if (it) methodreturn it }
}
to something like
def foo() {
try {
bar.each { if (it) throw new MethodReturnException(value:it) }
} catch (MethodReturnException e) {
return e.value
}
}
Would it be perhaps worth the effort to add such an ASTT to Groovy? Not sure at
all... but it might help (a) to stick with the canonical foo.each instead of
enforcing for/ins, (b) also, in many cases like foo.find, foo.allResults, et
cetera, which are even more ugly to replace with plain ole loops.
All the best,
OC
