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-316) Operator ?? has very low priority
Date Thu, 03 Oct 2019 08:11:00 GMT

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

Dmitri Blinov edited comment on JEXL-316 at 10/3/19 8:10 AM:
-------------------------------------------------------------

I have checked how in other languages the position of the null-coalescing operator is defined,
and results are very mixed. The languages like C#, Javascript (being proposed) place null
coalescing operand closer to ternary, like it is currently implemented in JEXL. Some languages
like PHP and freemarker are closer to what is being proposed. There are some like Swift that
are in between - above the arithmetic, but below comparisons, and not without the reason,
sinse comparisons are never null. Some languages do not have null coalescing operator at all,
but use *elvis* operator for this purpose, which they BTW, see as shortened form of ternary
operator, and as such, define the priority of elvis operator close to ternary. For me, for
example, this is also comes as no surprise  - I get used to elvis being a ternary sibling,
not a null coaliscing one. In some sence, IMO, the introduction of null coalescing operator
in JEXL is more justified when it differs from what we have already had.

So, the community has no single approach to the problem, and no industry-wide convention.
Lets leave it as it is for now.


was (Author: dmitri_blinov):
I have checked how in other languages the position of the null-coalescing operator is defined,
and results are very mixed. The languages like C#, Javascript (being proposed) place null
coalescing operand closer to ternary, like it is currently implemented in JEXL. Some languages
like PHP and freemarker are closer to what is being proposed. There are some like Swift that
are in between - above the arithmetic, but below comparisons. Some languages do not have null
coalescing operator at all, but use *elvis* operator for this purpose, which they BTW, see
as shortened form of ternary operator, and as such, define the priority of elvis operator
close to ternary. For me, for example, this is also comes as no surprise  - I get used to
elvis being a ternary sibling, not a null coaliscing one. In some sence, IMO, the introduction
of null coalescing operator in JEXL is more justified when it differs from what we have already
had.

So, the community has no single approach to the problem, and no industry-wide convention.
Lets leave it as it is for now.

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

Mime
View raw message