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

Max Tardiveau commented on JEXL-113:
------------------------------------

Hi Henri,

thanks for following up on this. My personal preference would be for an option 
to select between 1, 2 and the current behavior, but I don't know if that's 
just me?

We have a workaround for now, but if we had this option, we could throw away 
the workaround, so it would be quite useful.

In case you're curious, we need to determine dependencies from an expression -- 
which objects and attributes are accessed in the expression. We currently 
evaluate the expression and we use a custom context object that returns special 
objects that keep track of what gets accessed. It's not horrible, but it is 
more complicated than I'd like it to be.

Allow me to reiterate that this is a *very* useful library, and that we very 
much appreciate it.

Thanks again,

-- Max




> Dot notation behaves unexpectedly with null values
> --------------------------------------------------
>
>                 Key: JEXL-113
>                 URL: https://issues.apache.org/jira/browse/JEXL-113
>             Project: Commons JEXL
>          Issue Type: Bug
>    Affects Versions: 2.0.1
>         Environment: JDK 1.6
>            Reporter: Max Tardiveau
>
> When a variable of the form a.b is evaluated, the context is asked first for 
> the value of a. That value is then asked for the value of b.
> So far, so good: this is exactly what you'd expect from the dot operator.
> But if the value of b is null, the context is then asked for the value of 
> a.b, in other words the dot operator is ignored and "a.b" is considered to be 
> a single variable.
> This is at best confusing. Granted, this can be avoided with the a['b'] 
> notation, but that's clumsy.
> I assume this is an attempt to support both the dot operator and ant-style 
> variables. I don't think you can have both and remain sane.
> Suggestion: either document this behavior, or make it an option. My vote 
> would be to just use the value returned, even if it's null. Either dot is an 
> operator, or it's not. Perhaps make that configurable?
> Thanks!

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to