[
https://issues.apache.org/jira/browse/JEXL-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitri Blinov updated JEXL-168:
-------------------------------
Description: While overloaded '\+' operator basically works with Strings in
many cases, it works with them in unpredictable manner, for example, if we try
to concatenate two parts of IP address with expression "127.0" + "0.1" it will
give us the result 127.1 by successfully trying first to convert both operands
to numbers and perform addtion. In generic algorithm that combines two parts of
some code from database it is hard to say what characters those codes might be
consist of, and when this algorithm will eventually break. I understand that
this syntax has neverthelless a long history, and changing its behaviour may
break many legacy applications. And via the extension of JexlArithmetic we can
override *add* method to support different priority for Strings, but that just
means that default implementation of the very basic operation is not ideal. In
my case I consider refraining from usage of '\+' for Strings altogether and
overriding some other operator like '|', with less side effects, but anyway
constructs like 127 | 1 will divert to original implementation. So I suggest
that we could have a dedicated operator for concatenation, like for example in
"EL 3.0" they reserved "+=" for this purpose, and regardless of types of
operands it will convert to strings both parts and return concatenation. (was:
While overloaded "+" operator basically works with Strings in many cases, it
works with them in unpredictable manner, for example, if we try to concatenate
two parts of IP address with expression "127.0" + "0.1" it will give us the
result 127.1 by successfully trying first to convert both operands to numbers
and perform addtion. In generic algorithm that combines two parts of some code
from database it is hard to say what characters those codes might be consist
of, and when this algorithm will eventually break. I understand that this
syntax has neverthelless a long history, and changing its behaviour may break
many legacy applications. And via the extension of JexlArithmetic we can
override *add* method to support different priority for Strings, but that just
means that default implementation of the very basic operation is not ideal. In
my case I consider refraining from usage of "+" for Strings altogether and
overriding some other operator like "|", with less side effects, but anyway
constructs like 127 | 1 will divert to original implementation. So I suggest
that we could have a dedicated operator for concatenation, like for example in
"EL 3.0" they reserved "+=" for this purpose, and regardless of types of
operands it will convert to strings both parts and return concatenation.)
> Dedicated operator for String concatenation
> -------------------------------------------
>
> Key: JEXL-168
> URL: https://issues.apache.org/jira/browse/JEXL-168
> Project: Commons JEXL
> Issue Type: Improvement
> Reporter: Dmitri Blinov
> Priority: Minor
> Fix For: 3.0
>
>
> While overloaded '\+' operator basically works with Strings in many cases, it
> works with them in unpredictable manner, for example, if we try to
> concatenate two parts of IP address with expression "127.0" + "0.1" it will
> give us the result 127.1 by successfully trying first to convert both
> operands to numbers and perform addtion. In generic algorithm that combines
> two parts of some code from database it is hard to say what characters those
> codes might be consist of, and when this algorithm will eventually break. I
> understand that this syntax has neverthelless a long history, and changing
> its behaviour may break many legacy applications. And via the extension of
> JexlArithmetic we can override *add* method to support different priority for
> Strings, but that just means that default implementation of the very basic
> operation is not ideal. In my case I consider refraining from usage of '\+'
> for Strings altogether and overriding some other operator like '|', with less
> side effects, but anyway constructs like 127 | 1 will divert to original
> implementation. So I suggest that we could have a dedicated operator for
> concatenation, like for example in "EL 3.0" they reserved "+=" for this
> purpose, and regardless of types of operands it will convert to strings both
> parts and return concatenation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
