<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 29/07/2011 14:28, Edson Tirelli wrote:
<blockquote
cite="mid:CAD7AJnc+U47ZJ=Kyt7x3_S=q=ERDasVt5WMOAWdZakjcMMMx2g@mail.gmail.com"
type="cite">
<div><br>
</div>
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:
<div><br>
</div>
<div>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<div>
a.b.c == null</div>
<div><br>
</div>
<div> 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</div>
<div><br>
</div>
<div>a[x].b[y].c[z] == null</div>
<div><br>
</div>
<div> 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. </div>
<div>
<br>
</div>
<div> 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.</div>
<div><br>
</div>
<div>> So, a builder option to turn this on is allright with
me.</div>
<div><br>
</div>
<div> We can probably do that and have a configuration option
to turn this feature on/off.</div>
</div>
</blockquote>
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.<br>
<br>
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).<br>
<br>
Mark<br>
<br>
Mark<br>
<blockquote
cite="mid:CAD7AJnc+U47ZJ=Kyt7x3_S=q=ERDasVt5WMOAWdZakjcMMMx2g@mail.gmail.com"
type="cite">
<div>
<div><br>
</div>
<div>
Edson</div>
<div><br>
</div>
<br>
<div class="gmail_quote">2011/7/29 Mark Proctor <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:mproctor@codehaus.org">mproctor@codehaus.org</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div bgcolor="#FFFFFF" text="#000000"> Lets forget that
these are nested accessors and the problems they bring.
Lets look at what they would be if they were real
relations:
<div class="im"><br>
<br>
On 29/07/2011 08:55, Wolfgang Laun wrote:
<blockquote type="cite">Whoa! See below...<br>
<br>
2011/7/28 Edson Tirelli <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ed.tirelli@gmail.com" target="_blank">ed.tirelli@gmail.com</a>></span><br>
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="border-left:1px solid rgb(204, 204,
204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"> <br>
<div> I think we need to differentiate paradigms
here. When using rules, contrary to imperative
code, what we are doing is pattern matching.</div>
<div><br>
</div>
<div>X( a.b.c == <value> )</div>
<div><br>
</div>
<div> 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.</div>
</blockquote>
<div><br>
(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! <br>
<br>
Is there no house at some address?<br>
(city.street[name].house[number] == null) #
true => no such house<br>
</div>
</div>
</blockquote>
</div>
$c : City()<br>
$s : Street( city == $c, street = "name" )<br>
House( number == null)<br>
<br>
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.
<div>
<div class="h5"><br>
<br>
<br>
<blockquote type="cite">
<div class="gmail_quote">
<div><br>
This test data with false when null:
Vienna/TirelliStrasse/42 returns "false", hence
there <i>is</i> such a house. But we don't have
a Tirelli Street in Vienna (yet)!<br>
<br>
Confer this to Perl's<br>
! exists $city{-streets}{"Tirelli"}[42]<br>
)<br>
</div>
<blockquote class="gmail_quote"
style="border-left:1px solid rgb(204, 204,
204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
<div> Raising a null pointer exception, IMO,
brings no advantage at all to the table... on
the contrary, makes writing rules more
difficult. </div>
</blockquote>
<div><br>
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? <br>
<br>
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.)<br>
<br>
I have no problem when folks want to take
shortcuts and live la dolce vita, but<br>
<em>I don't want to be led into the bog
without my consent.</em><br>
<br>
So, a builder option to turn this on is allright
with me.<br>
<br>
</div>
<blockquote class="gmail_quote"
style="border-left:1px solid rgb(204, 204,
204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
<div><br>
</div>
<div> Another example we had in the past:</div>
<div><br>
</div>
<div>class Circle implements Shape</div>
<div>class Square implements Shape</div>
<div><br>
</div>
<div>rule X</div>
<div>when</div>
<div> Circle() from $shapes</div>
<div>...</div>
<div><br>
</div>
<div> 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.</div>
</blockquote>
<div><br>
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.<br>
<br>
-W<br>
<br>
</div>
<blockquote class="gmail_quote"
style="border-left:1px solid rgb(204, 204,
204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
<div><br>
</div>
<div> So, IMO, all property navigation should
be null pointer safe in the LHS of the rules. </div>
<div><br>
</div>
<div> This is not what happens today, but I
think it should be fixed.</div>
<div><br>
</div>
<div> Edson</div>
<div><br>
</div>
<div> </div>
<br>
<br>
<div class="gmail_quote">2011/7/28 Vincent
LEGENDRE <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:vincent.legendre@eurodecision.com"
target="_blank">vincent.legendre@eurodecision.com</a>></span><br>
<blockquote class="gmail_quote"
style="border-left:1px solid rgb(204, 204,
204);margin:0pt 0pt 0pt
0.8ex;padding-left:1ex">
<div>
<div style="font-family:Times New
Roman;font-size:12pt;color:rgb(0, 0, 0)">Hi
all,<br>
<br>
I agree with W. : NPE should be the
default, and "null" cases behaviour
should be planned by programmers.<br>
But I am not sure about using a new
operator in rules (and do the update in
Guvnor ...). <br>
Why not using some drools annotations on
the getter specifying the behaviour of
an eval on a null value returned by this
getter ? <br>
And may be these annotation could be
added to an existing POJO via the
declared type syntax (just like event
role in fusion) ?<br>
<font color="#888888"><br>
Vincent.<br>
</font></div>
</div>
<br>
_______________________________________________<br>
rules-users mailing list<br>
<a moz-do-not-send="true"
href="mailto:rules-users@lists.jboss.org"
target="_blank">rules-users@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/rules-users"
target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
<br>
</blockquote>
</div>
<font color="#888888"><br>
<br clear="all">
<br>
-- <br>
Edson Tirelli<br>
JBoss Drools Core Development<br>
JBoss by Red Hat @ <a
moz-do-not-send="true"
href="http://www.jboss.com" target="_blank">www.jboss.com</a><br>
</font><br>
_______________________________________________<br>
rules-users mailing list<br>
<a moz-do-not-send="true"
href="mailto:rules-users@lists.jboss.org"
target="_blank">rules-users@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/rules-users"
target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
<br>
</blockquote>
</div>
<br>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
rules-users mailing list
<a moz-do-not-send="true" href="mailto:rules-users@lists.jboss.org" target="_blank">rules-users@lists.jboss.org</a>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a>
</pre>
</blockquote>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
rules-users mailing list<br>
<a moz-do-not-send="true"
href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/rules-users"
target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Edson Tirelli<br>
JBoss Drools Core Development<br>
JBoss by Red Hat @ <a moz-do-not-send="true"
href="http://www.jboss.com">www.jboss.com</a><br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
rules-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-users">https://lists.jboss.org/mailman/listinfo/rules-users</a>
</pre>
</blockquote>
<br>
</body>
</html>