[rules-users] Condition syntax to access Map
Mark Proctor
mproctor at codehaus.org
Fri Jul 29 09:16:42 EDT 2011
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
More information about the rules-users
mailing list