commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dmitri Blinov (Jira)" <j...@apache.org>
Subject [jira] [Comment Edited] (JEXL-307) Variable redeclaration option
Date Wed, 02 Oct 2019 08:25:00 GMT

    [ https://issues.apache.org/jira/browse/JEXL-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16942085#comment-16942085
] 

Dmitri Blinov edited comment on JEXL-307 at 10/2/19 8:24 AM:
-------------------------------------------------------------

If new feature, through configuration on engine level, or via provided script compilation
options, will trigger java-like local variable visibility rules, instead of existing ones,
it would be great step in right direction. This, however, IMO, should not influence context
variables in any way. We should be allowed to freely assign to new context variables from
any point. So, we can declare that, under new option, the following is correct - every variable
should have visibility inside the block where it is defined. Loop variables are visible until
the end of loop:
{code:java}
for (var i : items) {}; return i;{code}
Thus the above code should raise exception - undefined variable.

Also, we need to agree what to do with hoisted variables. My vision is that hoisted variables
should be allowed to be redefined. If we can draw parallels with java, in java this is a valid
code
{code:java}
    final String var1 = "3456";
    Object x = new Object() {
      public String toString() {
            String m = var1;
            String var1 = "2346";
            return var1;
      }
    }; {code}
I'm not sure about pragmas though. The pragmas are a little underdeveloped now. For example,
I would change the grammar to allow pragmas to be allowed only at the beginning of the script.
Now they can be specified anywere in the middle, insideĀ *if* or *while* loop, which is misleading,
as they are not executed anyway, and their meaning relates to the whole script, not to the
particular part. Plus, the debugger now does not reproduce them in the generated source code,
thus they are get lost. Placing pragmas strictly at the beginning would allow to solve this
problem, and allow them to be used for specifying any parsing options.


was (Author: dmitri_blinov):
If new feature, through configuration on engine level, or via provided script compilation
options, will trigger java-like local variable visibility rules, instead of existing ones,
it would be great step in right direction. This, however, IMO, should not influence context
variables in any way. We should be allowed to freely assign to new context variables from
any point. So, we can declare that, under new option, the following is correct - every variable
should have visibility inside the block where it is defined. Loop variables are visible until
the end of loop:
{code:java}
for (var i : items) {}; return i;{code}
Thus the above code should raise exception - undefined variable.

Also, we need to agree what to do with hoisted variables. My vision is that hoisted variables
should be treated like function argumens, in other words, they should not be allowed to be
redefined. This would guarantee the evaluation integrity.

I'm not sure about pragmas though. The pragmas are a little underdeveloped now. For example,
I would change the grammar to allow pragmas to be allowed only at the beginning of the script.
Now they can be specified anywere in the middle, insideĀ *if* or *while* loop, which is misleading,
as they are not executed anyway, and their meaning relates to the whole script, not to the
particular part. Plus, the debugger now does not reproduce them in the generated source code,
thus they are get lost. Placing pragmas strictly at the beginning would allow to solve this
problem, and allow them to be used for specifying any parsing options.

> Variable redeclaration option
> -----------------------------
>
>                 Key: JEXL-307
>                 URL: https://issues.apache.org/jira/browse/JEXL-307
>             Project: Commons JEXL
>          Issue Type: New Feature
>    Affects Versions: 3.1
>            Reporter: Dmitri Blinov
>            Assignee: Henri Biestro
>            Priority: Minor
>             Fix For: 3.2
>
>
> As of now, JEXL allows a script writer to redeclare a local variable during script evaluation.
> {code:java}
> var a = 1; var a = 2;{code}
> This may lead to potential errors with misspelled names and clashed variables. Checking
for already defined variable is a common feature of many languages. This feature can be implemented
in JEXL as an additional option of JexlFeatures class, enabled by default, thus allowing compatibility
with existing code.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message