Whoa! See below...
2011/7/28 Edson Tirelli <ed.tirelli(a)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(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users