[rules-users] Condition syntax to access Map
Greg Barton
greg_barton at yahoo.com
Fri Jul 29 12:50:27 EDT 2011
Ah, other engines don't do nested accessors because they're wimps. WIMPS! :)
--- On Fri, 7/29/11, Mark Proctor <mproctor at codehaus.org> wrote:
From: Mark Proctor <mproctor at codehaus.org>
Subject: Re: [rules-users] Condition syntax to access Map
To: rules-users at lists.jboss.org
Date: Friday, July 29, 2011, 8:52 AM
On 29/07/2011 14:28, Edson Tirelli wrote:
Yes, that is exactly what I think. Pattern matching constraints
are like query parameters. They need to exist and evaluate to true
in order to match. So, for this to match:
a.b.c == null
a needs to exist and be non-null, b needs to exist and
be non-null, c needs to exist and be null. So it is not just
NP safe navigation... it is an existence test at the same
time. So for maps
a[x].b[y].c[z] == null
The keys x, y and z need to exist, and c[z] must have a
value of null. That is what the expression above is asking
for, in my understanding.
This presents no loss of completeness to the language,
as you can still test non-existence of keys if that is what
you want, but the most common case you are looking for the
opposite and it becomes much simpler to write rules that way.
> So, a builder option to turn this on is allright with
me.
We can probably do that and have a configuration option
to turn this feature on/off.
I'm strongly against configuration options in this case, we decide
on one way and stick with it. We already have too many
configurations and a casual person looking at the code could
introduce a bug as they weren't aware of what configuratino was on
for null safety.
I think part of the problem here is we are mixing domains, between
script evaluation and relational constraints. There is a reason why
other rule engines don't do nested accessors :) (ignoring the
technical issues too).
Mark
Mark
Edson
2011/7/29 Mark Proctor <mproctor at codehaus.org>
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>
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>
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
_______________________________________________
rules-users mailing list
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
--
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
-----Inline Attachment Follows-----
_______________________________________________
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/d03cde12/attachment.html
More information about the rules-users
mailing list