<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=utf-8"><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><br></div><div>
Edson</div><div><br></div><br><div class="gmail_quote">2011/7/29 Mark Proctor <span dir="ltr"><<a 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 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></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 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 href="mailto:rules-users@lists.jboss.org" target="_blank">rules-users@lists.jboss.org</a><br>
<a 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 href="http://www.jboss.com" target="_blank">www.jboss.com</a><br>
</font><br>
_______________________________________________<br>
rules-users mailing list<br>
<a href="mailto:rules-users@lists.jboss.org" target="_blank">rules-users@lists.jboss.org</a><br>
<a 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 href="mailto:rules-users@lists.jboss.org" target="_blank">rules-users@lists.jboss.org</a>
<a 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 href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<a 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 href="http://www.jboss.com">www.jboss.com</a><br>
</div>