Re: [rules-users] Condition syntax to access Map

Ah, other engines don't do nested accessors because they're wimps. WIMPS! :)

--- On *Fri, 7/29/11, Mark Proctor /&lt;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. > > > So, a builder option to turn this on is allright with 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 > </mc/compose?to=mproctor(a)codehaus.org&gt;&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 >> </mc/compose?to=ed.tirelli(a)gmail.com&gt;&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 >> </mc/compose?to=vincent.legendre(a)eurodecision.com&gt;&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 >> </mc/compose?to=rules-users(a)lists.jboss.org&gt; >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> >> >> >> -- >> Edson Tirelli >> JBoss Drools Core Development >> JBoss by Red Hat @ www.jboss.com <http://www.jboss.com> >> >> _______________________________________________ >> rules-users mailing list >> rules-users(a)lists.jboss.org >> </mc/compose?to=rules-users(a)lists.jboss.org&gt; >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> >> >> >> _______________________________________________ >> rules-users mailing list >> rules-users(a)lists.jboss.org </mc/compose?to=rules-users(a)lists.jboss.org&gt; >> https://lists.jboss.org/mailman/listinfo/rules-users > > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > </mc/compose?to=rules-users(a)lists.jboss.org&gt; > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > -- > Edson Tirelli > JBoss Drools Core Development > JBoss by Red Hat @ www.jboss.com <http://www.jboss.com> > > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org </mc/compose?to=rules-users(a)lists.jboss.org&gt; > https://lists.jboss.org/mailman/listinfo/rules-users -----Inline Attachment Follows----- _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org </mc/compose?to=rules-users(a)lists.jboss.org&gt; 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