[rules-users] Condition syntax to access Map

[Mark Proctor]

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 at gmail.com 
> <mailto:ed.tirelli at 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 at eurodecision.com
>     <mailto: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 <mailto: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>
>
>     _______________________________________________
>     rules-users mailing list
>     rules-users at lists.jboss.org <mailto: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/20110729/8f66d851/attachment.html