[
https://issues.apache.org/jira/browse/JEXL-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16941028#comment-16941028
]
Henri Biestro edited comment on JEXL-307 at 9/30/19 3:21 PM:
-------------------------------------------------------------
This leads to a feature / option that implements a script *lexical scope*. The
canonical illustration is the difference between the JavaScript 'var' and 'let'
with respect to parameters and local variable definitions.
As a *feature* (JexlFeature), this 'lexical' mode will fail parsing when a
variable/parameter redefinition is attempted in the same scope; from the point
of definition within a block/function, a variable can not be redefined.
An an *option* (JexlOption), the same lexical rule applies but whether an
exception is thrown or logged is subject to the exception handling rules in
effect. This runtime behaviour should be easily turned on or off (driven though
pragma for instance) so that large existing scripts libraries can be converted
to the new semantic through managed evolution (ie one script at a time).
To be consistent with the intent - avoid variable misnaming -, global variables
can no longer be defined in this mode; they must be declared (aka JexlContext
has() method returns true) first. This can only be detected at runtime.
{code}{ var c = 42; ...} d = 169; {code} should fail if the context does not
declares 'd'.
This also implies that after a variable/parameter is declared and outside of
its definition scope, references to that variable will generate an 'undefined
variable' error. The effect is that a local variable can no longer be confused
with a global one.
{code}{ var c = 42; ...} c + 157; {code} should fail with reporting an
undefined variable 'c'.
So should:
{code}{ var c = 42; ...} c = 157; {code}
was (Author: henrib):
This leads to a feature / option that implements a script lexical scope. The
canonical illustration is the difference between the JavaScript 'var' and 'let'
with respect to parameters and local variable definitions.
As a feature (JexlFeature), this 'lexical' mode will fail parsing when a
variable/parameter redefinition is attempted in the same scope; from the point
of definition within a block/function, a variable can not be redefined.
An an option (JexlOption), the same lexical rule applies but whether an
exception is thrown or logged is subject to the exception handling rules in
effect. This runtime behaviour should be easily turned on or off (driven though
pragma for instance) so that large existing scripts libraries can be converted
to the new semantic through managed evolution (ie one script at a time).
To be consistent with the intent - avoid variable misnaming -, global variables
can no longer be defined in this mode; they must be declared (aka JexlContext
has() method returns true) first. This can only be detected at runtime.
{code}{ var c = 42; ...} d = 169; {code} should fail if the context does not
declares 'd'.
This also implies that after a variable/parameter is declared and outside of
its definition scope, references to that variable will generate an 'undefined
variable' error. The effect is that a local variable can no longer be confused
with a global one.
{code}{ var c = 42; ...} c + 157; {code} should fail with reporting an
undefined variable 'c'.
So should:
{code}{ var c = 42; ...} c = 157; {code}
> 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 and 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)
