[jira] [Commented] (JEXL-113) Dot notation behaves unexpectedly with null values
[ https://issues.apache.org/jira/browse/JEXL-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063529#comment-13063529 ] Gary D. Gregory commented on JEXL-113: -- Hi Max, can you ping me at ggreg...@apache.org? I think we've worked together before... > 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 >Assignee: Henri Biestro > > 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
[jira] [Commented] (JEXL-113) Dot notation behaves unexpectedly with null values
[ https://issues.apache.org/jira/browse/JEXL-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063518#comment-13063518 ] Max Tardiveau commented on JEXL-113: Got it. That makes sense. Thanks, -- 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
[jira] [Commented] (JEXL-113) Dot notation behaves unexpectedly with null values
[ https://issues.apache.org/jira/browse/JEXL-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063263#comment-13063263 ] Henri Biestro commented on JEXL-113: The reason for the Set> would be to track both 'dot' operators and 'bracketed' expressions since they dont differ in evaluation. Every 'dot' expr can be rewritten as a 'bracketed' expr (not the opposite because of restrictions in allowed characters for identifiers). Anyway, reusing your example: a + b.c + d[e][f] would return { {"a"}, {"b", "c"}, {"d", "e", "f"} } However, a + b[func()] would only return { {"a"}, {"b"} } Cheers, Henri > 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
[jira] [Commented] (JEXL-113) Dot notation behaves unexpectedly with null values
[ https://issues.apache.org/jira/browse/JEXL-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13062697#comment-13062697 ] Max Tardiveau commented on JEXL-113: That would be ideal! But I'm not sure I understand the return value. If my expression is: a + b.c + d.e.f I assume I'd get: { {"a"}, {"b", "c"}, {"d", "e", "f"} } I think a return type of Set would be sufficient, since parsing dots should probably be left to the caller (since only they know what the dots mean). So I'd just get: { "a", "b.c", "d.e.f" } which would be adequate. Either way would work, of course, I'm just trying to figure out what makes the most sense. Thanks! -- 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
[jira] [Commented] (JEXL-113) Dot notation behaves unexpectedly with null values
[ https://issues.apache.org/jira/browse/JEXL-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13062391#comment-13062391 ] Henri Biestro commented on JEXL-113: Hi Max, So, your functional need is extracting which variables are used to evaluate a script. I've had the same need for a while. So maybe an 'extractDependencies' method could be more useful than fumbling with the 'dot' operator behavior. Its signature could be: Set> JexlEngine.extractDependencies(Script script). Each entry in the returned set would be the list of constant 'names' used in references aka dot or bracket expressions. Would this be adequate ? Cheers Henri PS/ thanks for the positive reinforcement :-) > 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
[jira] [Commented] (JEXL-113) Dot notation behaves unexpectedly with null values
[ 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
[jira] [Commented] (JEXL-113) Dot notation behaves unexpectedly with null values
[ https://issues.apache.org/jira/browse/JEXL-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13060990#comment-13060990 ] Henri Biestro commented on JEXL-113: Hi Max, Not sure which way to go: 1/ allow an option to prevent the 'dot' operator: all variables are 'antish' and array access is needed to get to properties? 2/ allow an option to prevent the 'antish' variables; no variable can be 'antish', the 'dot' operator always accesses a property? 3/ another solution would be to white-list classes / properties to restrict which ones can participate in the 'dot'/'array-reference' resolution Any opinion, preferred choice ? Cheers Henrib > 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
[jira] [Commented] (JEXL-113) Dot notation behaves unexpectedly with null values
[ https://issues.apache.org/jira/browse/JEXL-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13053809#comment-13053809 ] Max Tardiveau commented on JEXL-113: Hi Henri, we love Jexl! It's not uncommon for this type of library to be widely used, but very much under-recognized. Please know that we use it, and we like it. After some more thinking about this, I can now see that handling null values is a challenge. Maybe we could have the option to turn off the dot operator? That would allow us to resolve the dot operator in our context class, and perhaps come up with a way to handle nulls (e.g. return zero instead of null). This can be done now with proxy classes, or by encapsulating beans, but that seems like a lot of work. In the meantime, we're going to turn on silent mode, and let nulls be treated as they are now. Thanks for a valuable library! -- 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
[jira] [Commented] (JEXL-113) Dot notation behaves unexpectedly with null values
[ https://issues.apache.org/jira/browse/JEXL-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13052561#comment-13052561 ] Henri Biestro commented on JEXL-113: Jexl since 1.0 has always been supporting ant-ish variable naming as well as the dot operator; it was thus important to continue supporting this feature (especially since the jexl user community is scattered and mostly silent :-( ). I doagree this behavior is anyway under-documented. Note that variable resolution does not (should not) confuse the case if a conflict can occur; ant-ish variables are only tried if no bean exists during the dotted-path resolution. I'll try adding a 'no-antish vars' flag to the interpreter if this accommodates your needs and allows regaining "sanity". If you were to attach a (junit) test case checking for the desired behavior(s), it will definitely help speed up coming up with a proper solution. > 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