[rules-users] Condition syntax to access Map

[Joe White]

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 at lists.jboss.org
[mailto:rules-users-bounces at lists.jboss.org] On Behalf Of Mark Proctor
Sent: Thursday, July 28, 2011 1:35 PM
To: rules-users at 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 at gmail.com>
<mailto:ed.tirelli at gmail.com>  wrote:




From: Edson Tirelli <ed.tirelli at gmail.com> <mailto:ed.tirelli at gmail.com>

Subject: Re: [rules-users] Condition syntax to access Map
To: "Rules Users List" <rules-users at lists.jboss.org>
<mailto:rules-users at 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 at 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 at 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 at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users






_______________________________________________
rules-users mailing list
rules-users at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20110728/1edfd423/attachment.html