[
https://issues.apache.org/jira/browse/JEXL-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12746469#action_12746469
]
Henri Biestro edited comment on JEXL-87 at 8/22/09 11:08 AM:
-------------------------------------------------------------
About literals, it could be convenient & easy to add syntactic notations for
the different literal types :
123L for (Long) 123
12.3d for Double
12.3D for BigDecimal (capital 'D'))
123I for BigInteger (capital 'I')
On the arithmetic itself, it might be easier on the user-end to follow more
common rules about types by avoiding automatic conversion & add coercion
operators (or functions in the global namespace) - applying the "lesser
surprise principle".
The "more common rules" would be composition rules based on a usual datatype
ordering:
String > BigDecimal > Double > BigInteger > Long > Character > Int > Short >
Byte
And all operations would do:
{code}
x o y -> Compose(type(x), type(y)).o(x,y)
{code}
With compose being:
{code}
Compose(Double, BigInteger) -> BigDecimal
Composte(t1, t2) -> Datatype.Max(t1, t2)
{code}
And each datatype implement its own code for each operation.
Since arithmetic operations could then overflow, we'd introduce explicit
coercions to let users circumvent these cases.
I however suspect such a scheme would be further away from the JSF/JSP EL spec.
WDYT ?
was (Author: henrib):
About literals, it could be convenient & easy to add syntactic notations
for the different literal types :
123L for (Long) 123
12.3d for Double
12.3D for BigDecimal (capital 'D'))
123I for BigInteger (capital 'I')
On the arithmetic itself, it might be easier on the user-end to follow more
common rules about types by avoiding automatic conversion & add coercion
operators (or functions in the global namespace) - applying the "lesser
surprise principle".
The "more common rules" would be composition rules based on a usual datatype
ordering:
String > BigDecimal > Double > BigInteger > Long > Character > Int > Short >
Byte
And all operations would do:
x o y -> Compose(type(x), type(y)).o (x,y)
With compose being:
Compose(Double, BigInteger) -> BigDecimal
Composte(t1, t2) -> Datatype.Max(t1, t2)
And each datatype implement its own code for each operation.
Since arithmetic operations could then overflow, we'd introduce explicit
coercions to let users circumvent these cases.
I however suspect such a scheme would be further away from the JSF/JSP EL spec.
WDYT ?
> Inconsistent behaviour of arithmetical operations
> -------------------------------------------------
>
> Key: JEXL-87
> URL: https://issues.apache.org/jira/browse/JEXL-87
> Project: Commons JEXL
> Issue Type: Bug
> Reporter: Sebb
> Fix For: 2.0
>
>
> BigInteger(7) / BigInteger(2) == 3
> whereas
> BigDecimal(7) / BigDecimal(2) == 4, because the result is rounded up.
> I would expect the results to be the same.
> Rather worse is:
> BigDecimal(7) % BigDecimal(2) == -1
> which makes no sense at all.
> Seems to me that the arithmetic "rules" need revisiting and rationalising -
> for example why should Integer be treated as double?
> At present literal numbers are treated as Integer or Float; there's no option
> to generate Long or Double literals.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
