You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Dmitri Blinov (JIRA)" <ji...@apache.org> on 2016/07/10 11:57:11 UTC

[jira] [Commented] (JEXL-203) JexlArithmetic.options() diverts Interpreter to use default implementation of JexlArithmetic instead of custom one

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

Dmitri Blinov commented on JEXL-203:
------------------------------------

I think more appropriate solution to this would be following the factory pattern although at the cost of breaking up existing API and binary compatibility. 

For example there would be an interface 

{code}
public interface ArithmeticFactory {
   // default
   public JexlArithmetic createArithmetic();

   // with options
   public JexlArithmetic createArithmetic(JexlEngine.Options options);
}
{code}

JexlEngine then should be changed to be iniitialized not with the instance of JexlArithmetic class but instead with an implementation of ArithmeticFactory where one can choose between the default JexlArithmeticFactory which would instantiate instances of existing JexlArithmetic class or provide an extended ArithmeticFactory that would instantiate instances of desired type.

Thus the developer will be given clear understanding of what is required from him/her to extend JexlArithmetic behaviour.

> JexlArithmetic.options() diverts Interpreter to use default implementation of JexlArithmetic instead of custom one
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: JEXL-203
>                 URL: https://issues.apache.org/jira/browse/JEXL-203
>             Project: Commons JEXL
>          Issue Type: Bug
>            Reporter: Dmitri Blinov
>
> If JexlContext implements JexlEngine.Options and it provides values for strictness, scale and MathContext that are different from what was specified during creation of JexlArithmetics, then instance of wrong JexlArithmetic class is created instead of custom class previously used. Apparently the JexlArithmetic.options() method could then be overloaded in custom class, but I don't like the idea of copying all that code from version to version, so may be more robust solution could be found to this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)