Whoa! See below... 2011/7/28 Edson Tirelli <ed.tire...@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 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.legen...@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@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > >
_______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users