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

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.

Edson 2011/7/29 Mark Proctor <mproctor(a)codehaus.org <mailto:mproctor@codehaus.org>> 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 > <mailto:ed.tirelli@gmail.com>> > > > 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 > <mailto:vincent.legendre@eurodecision.com>> > > 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 > <mailto:rules-users@lists.jboss.org> > 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 <mailto:rules-users@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org> 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 https://lists.jboss.org/mailman/listinfo/rules-users