[rules-users] Condition syntax to access Map

[Mark Proctor]

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>/* wrote:
>
>
>     From: Edson Tirelli <ed.tirelli at gmail.com>
>     Subject: Re: [rules-users] Condition syntax to access Map
>     To: "Rules Users List" <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
>     </mc/compose?to=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
>         </mc/compose?to=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 <http://www.jboss.com>
>
>     -----Inline Attachment Follows-----
>
>     _______________________________________________
>     rules-users mailing list
>     rules-users at lists.jboss.org
>     </mc/compose?to=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/2ccb8182/attachment.html