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

I'm 100% with Edson on this one. Requiring explicit syntax, whether via null checks or .?, can have a big impact on the clarity and level of declarativeness (word?) of a given ruleset. It also makes it a great deal harder to develop DSLs and systems to put rules into the hands of non-developers because then you're requiring those users to bring with them the imperative programming mindset of checking every data point before using it. I think that Edson's example of making the whole expression false if any object on the call stack is null independent of the value is an excellent convention. Joe From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Mark Proctor Sent: Thursday, July 28, 2011 1:35 PM To: rules-users(a)lists.jboss.org Subject: Re: [rules-users] Condition syntax to access Map 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: +1 Naw.... +billion --- On Thu, 7/28/11, Edson Tirelli <ed.tirelli(a)gmail.com&gt; <mailto:ed.tirelli@gmail.com> wrote: From: Edson Tirelli <ed.tirelli(a)gmail.com&gt; <mailto:ed.tirelli@gmail.com> Subject: Re: [rules-users] Condition syntax to access Map To: "Rules Users List" <rules-users(a)lists.jboss.org&gt; <mailto:rules-users@lists.jboss.org> Date: Thursday, July 28, 2011, 1:13 PM 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; 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 -----Inline Attachment Follows----- _______________________________________________ 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