[
https://issues.apache.org/jira/browse/JEXL-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16621554#comment-16621554
]
Dmitri Blinov edited comment on JEXL-269 at 9/20/18 6:05 AM:
-------------------------------------------------------------
You have coined right term for it, *iteration counter*, so I updated the ticked
to be more precise. The counter is the automatically maintained variable, which
frees the script-writer from burden to write supplementary code.
The exact analogy would be as this:
{code}
for(var item : list) { var i = not empty(i) ? i + 1 : 0; ... }
{code}
since, in the proposed implementation, the counter variable {{i}} should not be
initialized to {{0}} if {{list}} is {{null}}, which would help to check it for
being {{not empty()}} to understand if there was something for the loop to
iterate over.
Under the hood the iteration counter is not used for accessing iterator
elements, so I don't see how it could hurt performance.
As for maps, again, the proposed implementation allows for a script writer to
write a little less of supplementary code. Compare the expressiveness of
{code}
for (var e : map?.entrySet()) {
var key = e.key;
var value = e.value;
....
}
{code}
with
{code}
for (var key, value : map) {
....
}
{code}
BTW, With latter you mustn't remember how exactly that method returning entries
on the map is named :-)
Overall, the general idea of the last PRs is only little the-quality-of-life
improvements. These are not game-changers, and basically are not more than a
hundred lines of code.
was (Author: dmitri_blinov):
You have coined right term for it, *iteration counter*, so I updated the ticked
to be more precise. The counter is the automatically maintained variable, which
frees the script-writer from burden to write supplementary code.
The exact analogy would be as this:
{code}
for(var item : list) { var i = not empty(i) ? i + 1 : 0; ... }
{code}
since, in the proposed implementation, the counter variable {{i}} should not be
initialized to {{0}} if {{list}} is {{null}}, which would help to check it for
being {{not empty()}} to understand if there was something for the loop to
iterate over.
Under the hood the iteration counter is not used for accessing iterator
elements, so I don't see how it could hurt performance.
As for maps, again, the proposed implementation allows for a script writer to
write a little less of supplementary code. Compare the expressiveness of
{code}
for (var e : map?.entrySet()) {
var key = e.key;
var value = e.value;
....
}
{code}
with
{code}
for (var key, value : map) {
....
}
BTW, With latter you mustn't remember how exactly that method returning entries
on the map is named :-)
Overall, the general idea of the last PRs is only little the-quality-of-life
improvements. These are not game-changers, and basically are not more than a
hundred lines of code.
> Indexed for-loop
> ----------------
>
> Key: JEXL-269
> URL: https://issues.apache.org/jira/browse/JEXL-269
> Project: Commons JEXL
> Issue Type: New Feature
> Affects Versions: 3.1
> Environment: I have created a PR for this feature, please see
> [PR#12|https://github.com/apache/commons-jexl/pull/12]
> Reporter: Dmitri Blinov
> Priority: Minor
>
> Introduce new extended syntax of 'for' statement, which allows to specify two
> variables, like the following
> {code:java}
> for (var i, item : list){code}
> Inside the loop, the first variable gets current iteration counter, starting
> from 0, and the second variable gets current iterated value. The special
> consideration is taken for iteration over map entries, like the following
> {code:java}
> for(var key, entry : map){code}
> , in this case the first variable is the map key, and the second is the
> corresponding map value
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
