Mark Thanks for the info - although it was not actually the solution to my problem, it prompted me to look again at my assertion that there were not any null values. In actual fact answerData[0] was null ( I should have been checking for answerData[100]) and this was causing the error. You modified syntax is much tidier; I'm now using the following format: $a : Answer(answerData[0] != null && answerData[0].value_str == "Valves") This prevents the prior null pointer exception. Thanks for your input. David -- View this message in context: http://drools.46999.n3.nabble.com/Condition-syntax-to-access-Map-tp320442... Sent from the Drools: User forum mailing list archive at Nabble.com.

Thanks for the pointer to the MVEL documents - I can forsee null-safe operator user.?manager.name syntax being most useful. As for making the null test the default action - I'm not sure - I can't say I have ever actually 'wanted' a nullpointer - but there may be some special case. David -- View this message in context: http://drools.46999.n3.nabble.com/Condition-syntax-to-access-Map-tp320442... Sent from the Drools: User forum mailing list archive at Nabble.com.

On 28/07/2011 13:53, Wolfgang Laun wrote: ok, sounds like we just need to add .? support into our parser then - if it's not already supported. Mark

All, I think we need to differentiate paradigms here. When using rules, contrary to imperative code, what we are doing is pattern matching. X( a.b.c == <value> ) In the above case, we are looking for Xs that make that whole constraint true (i.e. match). If a or b are null, the whole expression will be false, does not matter the value of c or the value it is being compared against. Raising a null pointer exception, IMO, brings no advantage at all to the table... on the contrary, makes writing rules more difficult. Another example we had in the past: class Circle implements Shape class Square implements Shape rule X when Circle() from $shapes ... In the above example, $shapes is a list and the rule is clearly looking for Circles. If there are Squares in there, they will just not match. Raising a ClassCastException like it would happen in an imperative language brings no advantage to the table, IMO. So, IMO, all property navigation should be null pointer safe in the LHS of the rules. This is not what happens today, but I think it should be fixed. Edson 2011/7/28 Vincent LEGENDRE <vincent.legendre(a)eurodecision.com&gt; -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com

if we do implicit .? support people will still be able to do null checks. So it's not one or the other. Mark On 28/07/2011 20:07, Greg Barton wrote:

Whoa! See below... 2011/7/28 Edson Tirelli <ed.tirelli(a)gmail.com&gt; (Edson: Only if you define it so. The logical implication of c being null in an absent a.b (i.e., a.b==null) could very well be that "a.b.c does not exist", and you can't claim that a.b.c exists if a.b. doesn't! Is there no house at some address? (city.street[name].house[number] == null) # true => no such house This test data with false when null: Vienna/TirelliStrasse/42 returns "false", hence there *is* such a house. But we don't have a Tirelli Street in Vienna (yet)! Confer this to Perl's ! exists $city{-streets}{"Tirelli"}[42] ) Edson, Mark,... please do recall the times where you have had an NPE in the code in a boolean expression? How painful would it have been if Java would have returned "false", continuing to cover a coding error made elsewhere? Why don't other languages tolerate "null" silently? (Perl, the most pragmatic of all, doesn't - it has introduced an operator I can use or not.) I have no problem when folks want to take shortcuts and live la dolce vita, but <em>I don't want to be led into the bog without my consent.</em> So, a builder option to turn this on is allright with me. This is an entirely different matter than the previous one. I see no reason whatsoever, not to define this "from" as working with an implicit filter. -W

Yes, that is exactly what I think. Pattern matching constraints are like query parameters. They need to exist and evaluate to true in order to match. So, for this to match: a.b.c == null a needs to exist and be non-null, b needs to exist and be non-null, c needs to exist and be null. So it is not just NP safe navigation... it is an existence test at the same time. So for maps a[x].b[y].c[z] == null The keys x, y and z need to exist, and c[z] must have a value of null. That is what the expression above is asking for, in my understanding. This presents no loss of completeness to the language, as you can still test non-existence of keys if that is what you want, but the most common case you are looking for the opposite and it becomes much simpler to write rules that way. We can probably do that and have a configuration option to turn this feature on/off. Edson 2011/7/29 Mark Proctor <mproctor(a)codehaus.org&gt; > Lets forget that these are nested accessors and the problems they bring. > Lets look at what they would be if they were real relations: > > > On 29/07/2011 08:55, Wolfgang Laun wrote: > > Whoa! See below... > > 2011/7/28 Edson Tirelli <ed.tirelli(a)gmail.com&gt; > >> >> I think we need to differentiate paradigms here. When using rules, >> contrary to imperative code, what we are doing is pattern matching. >> >> X( a.b.c == <value> ) >> >> In the above case, we are looking for Xs that make that whole >> constraint true (i.e. match). If a or b are null, the whole expression will >> be false, does not matter the value of c or the value it is being compared >> against. >> > > (Edson: Only if you define it so. The logical implication of c being null > in an absent a.b (i.e., a.b==null) could very well be that "a.b.c does not > exist", and you can't claim that a.b.c exists if a.b. doesn't! > > Is there no house at some address? > (city.street[name].house[number] == null) # true => no such house > > $c : City() > $s : Street( city == $c, street = "name" ) > House( number == null) > > The above is identical logic to the more convenient form of nested > accessors, it's the proper relational form. In this case if there was no > Street, it wouldn't match. > > > > > This test data with false when null: Vienna/TirelliStrasse/42 returns > "false", hence there *is* such a house. But we don't have a Tirelli Street > in Vienna (yet)! > > Confer this to Perl's > ! exists $city{-streets}{"Tirelli"}[42] > ) > > >> Raising a null pointer exception, IMO, brings no advantage at all to the >> table... on the contrary, makes writing rules more difficult. >> > > Edson, Mark,... please do recall the times where you have had an NPE in the > code in a boolean expression? How painful would it have been if Java would > have returned "false", continuing to cover a coding error made elsewhere? > > Why don't other languages tolerate "null" silently? (Perl, the most > pragmatic of all, doesn't - it has introduced an operator I can use or not.) > > I have no problem when folks want to take shortcuts and live la dolce vita, > but > <em>I don't want to be led into the bog without my consent.</em> > > > >> Another example we had in the past: >> >> class Circle implements Shape >> class Square implements Shape >> >> rule X >> when >> Circle() from $shapes >> ... >> >> In the above example, $shapes is a list and the rule is clearly >> looking for Circles. If there are Squares in there, they will just not >> match. Raising a ClassCastException like it would happen in an imperative >> language brings no advantage to the table, IMO. >> > > This is an entirely different matter than the previous one. I see no reason > whatsoever, not to define this "from" as working with an implicit filter. > > -W > > > >> >> So, IMO, all property navigation should be null pointer safe in the >> LHS of the rules. >> >> This is not what happens today, but I think it should be fixed. >> >> Edson >> >> >> >> >> 2011/7/28 Vincent LEGENDRE <vincent.legendre(a)eurodecision.com&gt; >> >>> Hi all, >>> >>> I agree with W. : NPE should be the default, and "null" cases behaviour >>> should be planned by programmers. >>> But I am not sure about using a new operator in rules (and do the update >>> in Guvnor ...). >>> Why not using some drools annotations on the getter specifying the >>> behaviour of an eval on a null value returned by this getter ? >>> And may be these annotation could be added to an existing POJO via the >>> declared type syntax (just like event role in fusion) ? >>> >>> Vincent. >>> >>> _______________________________________________ >>> rules-users mailing list >>> rules-users(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-users >>> >>> >> >> >> -- >> Edson Tirelli >> JBoss Drools Core Development >> JBoss by Red Hat @ www.jboss.com >> >> _______________________________________________ >> rules-users mailing list >> rules-users(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> > > > _______________________________________________ > rules-users mailing listrules-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users > > > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com

Ah, other engines don't do nested accessors because they're wimps.  WIMPS! :) --- On Fri, 7/29/11, Mark Proctor <mproctor(a)codehaus.org&gt; wrote: From: Mark Proctor <mproctor(a)codehaus.org&gt; Subject: Re: [rules-users] Condition syntax to access Map To: rules-users(a)lists.jboss.org Date: Friday, July 29, 2011, 8:52 AM On 29/07/2011 14:28, Edson Tirelli wrote:    Yes, that is exactly what I think. Pattern matching constraints are like query parameters. They need to exist and evaluate to true in order to match. So, for this to match: a.b.c == null    a needs to exist and be non-null, b needs to exist and be non-null, c needs to exist and be null. So it is not just NP safe navigation... it is an existence test at the same time. So for maps a[x].b[y].c[z] == null    The keys x, y and z need to exist, and c[z] must have a value of null. That is what the expression above is asking for, in my understanding.     This presents no loss of completeness to the language, as you can still test non-existence of keys if that is what you want, but the most common case you are looking for the opposite and it becomes much simpler to write rules that way. me.    We can probably do that and have a configuration option to turn this feature on/off. I'm strongly against configuration options in this case, we decide on one way and stick with it. We already have too many configurations and a casual person looking at the code could introduce a bug as they weren't aware of what configuratino was on for null safety. I think part of the problem here is we are mixing domains, between script evaluation and relational constraints. There is a reason why other rule engines don't do nested accessors :) (ignoring the technical issues too). Mark Mark    Edson 2011/7/29 Mark Proctor <mproctor(a)codehaus.org&gt; Lets forget that these are nested accessors and the problems they bring. Lets look at what they would be if they were real relations: On 29/07/2011 08:55, Wolfgang Laun wrote: Whoa! See below... 2011/7/28 Edson Tirelli <ed.tirelli(a)gmail.com&gt;    I think we need to differentiate paradigms here. When using rules, contrary to imperative code, what we are doing is pattern matching. X( a.b.c == <value> )    In the above case, we are looking for Xs that make that whole constraint true (i.e. match). If a or b are null, the whole expression will be false, does not matter the value of c or the value it is being compared against. (Edson: Only if you define it so. The logical implication of c being null in an absent a.b (i.e., a.b==null) could very well be that "a.b.c does not exist", and you can't claim that a.b.c exists if a.b. doesn't! Is there no house at some address?     (city.street[name].house[number] == null)  # true => no such house $c : City() $s : Street( city == $c, street = "name" )        House( number ==  null) The above is identical logic to the more convenient form of nested accessors, it's the proper relational form. In this case if there was no Street, it wouldn't match. This test data with false when null: Vienna/TirelliStrasse/42 returns "false", hence there is such a house. But we don't have a Tirelli Street in Vienna (yet)! Confer this to Perl's     ! exists $city{-streets}{"Tirelli"}[42] )   Raising a null pointer exception, IMO, brings no advantage at all to the table... on the contrary, makes writing rules more difficult.  Edson, Mark,... please do recall the times where you have had an NPE in the code in a boolean expression? How painful would it have been if Java would have returned "false", continuing to cover a coding error made elsewhere? Why don't other languages tolerate "null" silently? (Perl, the most pragmatic of all, doesn't - it has introduced an operator I can use or not.) I have no problem when folks want to take shortcuts and live la dolce vita, but <em>I don't want to be led into the bog without my consent.</em> So, a builder option to turn this on is allright with me.    Another example we had in the past: class Circle implements Shape class Square implements Shape rule X when     Circle() from $shapes ...    In the above example, $shapes is a list and the rule is clearly looking for Circles. If there are Squares in there, they will just not match. Raising a ClassCastException like it would happen in an imperative language brings no advantage to the table, IMO. This is an entirely different matter than the previous one. I see no reason whatsoever, not to define this "from" as working with an implicit filter. -W      So, IMO, all property navigation should be null pointer safe in the LHS of the rules.     This is not what happens today, but I think it should be fixed.    Edson       2011/7/28 Vincent LEGENDRE <vincent.legendre(a)eurodecision.com&gt; Hi all, I agree with W. : NPE should be the default, and "null" cases behaviour should be planned by programmers. But I am not sure about using a new operator in rules (and do the update in Guvnor ...). Why not using some drools annotations on the getter specifying the behaviour of an eval on a null value returned by this getter ? And may be these annotation could be added to an existing POJO via the declared type syntax (just like event role in fusion) ? Vincent. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users --   Edson Tirelli   JBoss Drools Core Development   JBoss by Red Hat @ www.jboss.com _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users --   Edson Tirelli   JBoss Drools Core Development   JBoss by Red Hat @ www.jboss.com _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -----Inline Attachment Follows----- _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

2011/7/31 Mark Proctor <mproctor(a)codehaus.org&gt; So what if Address is not an inserted fact? So far, a CE with type Foo(...) implied the existence of a fact of that type. I'm not sure that inserting some object should imply the insertion of all of its descendants as facts as well... -W

2011/7/31 Mark Proctor <mproctor(a)codehaus.org&gt; Surely you mean that changes to Address should result in an update notification for the owning Person object. - But that's not what I meant. The LHS Person(...) alone fires due a Person inserted and not when an Address is inserted; it fires again if a Person() update is signalled. In contrast, Person() Address(...) fires after both have been inserted and again after *either one* has been updated. This "references" I doubt very much. Surely you can "insert" anything. And joins are possible on (primary key attributes as well. The notation a.b.c reflects an implementation technique for a hierarchical data type. (Traditionally, x-dot-y means "add the offset for y to the address resulting from x".) A more general concept for "navigation" in a data structure would have to separate a logical relationship from the implementation technique. It may be necessary to retain the "dot" notation for the hard coded access and to devise an entirely new notation for logical navigation. As a somewhat contrived example, assume that Address is stored as a map field with key "addr" and the street is the second text line of the address: declare Person name : String # default implementation as "JBean field" props : Map address : Address as props["addr"] # the implementation end declare Address lines : String[] street : String as lines[1] end Person( name == "Psmith", address/street == "Main Drag" ) Car( owner/address/street ... ) # Person owner Notice that explicitly using props["addr"] or lines[1] is just another implementation dependent notation which breaks as soon as someone decides to change it in the class. Such things should not permeate application code. Also, notice that a "navigation expression" could be dynamic, making navigation dependent on the object's state, or whatever. -W