[rules-users] Condition syntax to access Map

[Wolfgang Laun]

Whoa! See below...

2011/7/28 Edson Tirelli <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

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>
>
>> 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
>
> _______________________________________________
> 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/2cbfc403/attachment.html