You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Dmitri Blinov (JIRA)" <ji...@apache.org> on 2018/09/20 06:06:00 UTC

[jira] [Comment Edited] (JEXL-269) Indexed for-loop

    [ 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)