>> One option versus adding a constructor would be to add a "forS" factory
>> overload to GeneralUtils that supports classical "for (int i = 0; i < n;
>> ++i) ..." > without making reference to the dummy variable.
> I am not sure I fully understand what you are suggesting. If we want to not
> make reference to the dummy variable in GeneralUtils, do we change the
> existing constructor to convert null to the dummy value?
My suggestion is about leaving ForStatement as-is and adding this to
GeneralUtls:
public static ForStatement forS(Expression threeParts, Statement loopBlock) {
return new ForStatememt(ForStatement.FOR_LOOP_DUMMY, threeParts, loopBlock);
}
Thus you could limit the use of FOR_LOOP_DUMMY to just here for now. I'd have
to look more at how a counting loop is built to see if Expression should be
something else.
Maybe it makes sense to add this for the 3-part classical counting loop — just
a thought at this point:
public static ForStatement forS(Expression variables, Expression conditions,
Expression whatevers, Statement loopBlock) {
return new ForStatememt(..., loopBlock);
}
________________________________
From: Paul King <[email protected]>
Sent: Friday, February 6, 2026 4:21 PM
To: [email protected] <[email protected]>
Subject: Re: Feedback on ForStatement
On Sat, Feb 7, 2026 at 2: 10 AM Milles, Eric (TR Technology) via dev <dev@
groovy. apache. org> wrote: > > I tried to make minimal changes when adding
index variable to ForStatement. It seemed that getValueVariable() and
getIndexVariable()
On Sat, Feb 7, 2026 at 2:10 AM Milles, Eric (TR Technology) via dev
<[email protected]> wrote:
>
> I tried to make minimal changes when adding index variable to ForStatement.
> It seemed that getValueVariable() and getIndexVariable() was the cleanest
> extension of getVariable() (now deprecated). One option versus adding a
> constructor would be to add a "forS" factory overload to GeneralUtils that
> supports classical "for (int i = 0; i < n; ++i) ..."
> without making reference to the dummy variable.
I am not sure I fully understand what you are suggesting. If we want
to not make reference to the dummy variable in GeneralUtils, do we
change the existing constructor to convert null to the dummy value?
> A bolder approach would be to separate "for (x in y)" from "for (int i = 0; i
> < n; ++i)" as distinct statement classes. Maybe they extend from
> ForStatement to keep visitors happy.
>
>
> When getIndexVariable() and getValueVariable() were introduced, I designed
> them so you could use them equally. That is, they return null when no index
> or value variable was given. To that end, I would not want to see
> hasValueVariable() and hasIndexVariable() introduced. You should be able to
> do any "if (hasValueVariable()) f(getValueVaruable())" with
> "Optional.ofNullable(getValueVaruable()).ifPresent(v -> f(v))" or of course
> "var v = getValueVariable(); if (v != null) f(v);".
>
> In summary, I'd favor a light tough for a refactoring; add as little as
> possible to the statement class. Unless you are willing to separate the
> abstractions of collection and counting loops.
>
> Eric M.
