[jira] [Comment Edited] (JEXL-316) Operator ?? has very low priority

["Dmitri Blinov (Jira)" <ji...@apache.org>]

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

Dmitri Blinov edited comment on JEXL-316 at 10/1/19 7:24 AM:
-------------------------------------------------------------

The difference is subtle yet significant. The ability of elvis operator to handle logical expressions places it to the higher league. One can expect to use elvis operator to calculate complicated conditions, may be even with side effects, like {code}transferAmount = checkAccountBalance(x) && lockAmount(y) ?: 0{code}, where its ability to evaluate left part only once really kicks in. On the other hand, the null coalescing operator is only needed to protect from *null* values from undefined variables and properties to leak into calculation, like {{a + b??2}}. In most cases this is expected to be {{a + (b??2)}} and not {{(a+b)??2}}, since its natural, though not totally impossible, for any arithmetic calculation or logical conditions not to produce null results. 

Personally I think elvis operator is strange and its usage is questionable, I have never found the reason to use it except may be only once or twice. And personally I don't care much. But for compatibility reasons I would let it be as it is.



was (Author: dmitri_blinov):
The difference is subtle yet significant. The ability of elvis operator to handle logical expressions places it to the higher league. One can expect to use elvis operator to calculate complicated conditions, may be even with side effects, like {{transferAmount = checkAccountBalance(x) && lockAmount(y) ?: 0}}, where its ability to evaluate left part only once really kicks in. On the other hand, the null coalescing operator is only needed to protect from *null* values from undefined variables and properties to leak into calculation, like {{a + b??2}}. In most cases this is expected to be {{a + (b??2)}} and not {{(a+b)??2}}, since its natural, though not totally impossible, for any arithmetic calculation or logical conditions not to produce null results. 

Personally I think elvis operator is strange and its usage is questionable, I have never found the reason to use it except may be only once or twice. And personally I don't care much. But for compatibility reasons I would let it be as it is.


> Operator ?? has very low priority
> ---------------------------------
>
>                 Key: JEXL-316
>                 URL: https://issues.apache.org/jira/browse/JEXL-316
>             Project: Commons JEXL
>          Issue Type: Bug
>    Affects Versions: 3.1
>            Reporter: Dmitri Blinov
>            Assignee: Henri Biestro
>            Priority: Major
>             Fix For: 3.2
>
>
> In current version of JEXL the script
> {code:java}
> 10??0 + 200 {code}
> evaluates to 10, which is counterintuitive. It requires to always use parantheses after {{\\??}}. The operator {{??}} should have higer priority. It is the same problem as with current version of freemarker, but they promise to fix it in the next major release.
> The suggestion is to set priority of operator {{??}} to be between {{UnaryExpression()}} and {{ValueExpression()}}
> {code}
> void ConditionalExpression() #void : {}
> {
>   ConditionalOrExpression()
>   (
>     <QMARK> Expression() <COLON> Expression() #TernaryNode(3)
>   |
>     <ELVIS> Expression() #TernaryNode(2)
>   )?
> }
> ...
> void UnaryExpression() #void : {}
> {
>     <minus> UnaryExpression() #UnaryMinusNode(1)
>   |
>     <plus> UnaryExpression() #UnaryPlusNode(1)
>   |
>     <tilda> UnaryExpression() #BitwiseComplNode(1)
>   |
>     (<not>|<NOT>) UnaryExpression() #NotNode(1)
>   |
>     <EMPTY> UnaryExpression() #EmptyFunction(1)
>   |
>     <SIZE> UnaryExpression() #SizeFunction(1)
>   |
>     NullpExpression()
> }
> void NullpExpression() #void : {}
> {
>     ValueExpression()
>     (
>        <NULLP> ValueExpression() #NullpNode(2)
>     )*
> }
> {code}



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