<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 29/07/2011 17:50, Greg Barton wrote:
<blockquote
cite="mid:1311958227.3376.YahooMailClassic@web81505.mail.mud.yahoo.com"
type="cite">
<table border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
<td style="font: inherit;" valign="top">Ah, other engines
don't do nested accessors because they're wimps. WIMPS!
:)<br>
</td>
</tr>
</tbody>
</table>
</blockquote>
I'd like to see a situation where we have the convenience of nested
accessors, but mapping to fully relational joins. This is combine
with some nice XPATH like syntax too.<br>
<br>
Implicit mapping I call Managed Object Graphs MOGs. So you can write<br>
Person( address.street == "my road" )<br>
<br>
And that internally would get translated too<br>
$p : Person()<br>
Address( person == $p, street == "my road" )<br>
<br>
As there is no doubt that the current explicit bindings approach on
objects is too verbose and hard to read. Nested accessors add a lot
of readability.<br>
<br>
I also want to add xpath like syntax as a short cut for 'from', as I
think it makes for easier readability:<br>
Bookshop()/books( author == "some author" )<br>
<br>
Which is a short cut for:<br>
$b : Bookshop<br>
Book( author == "some author" ) from $b.books<br>
<br>
And would support map/list access like xpath:<br>
Person()/pets[0]/( age > 30)<br>
<br>
Whichis short for<br>
$p : Person()<br>
Pet( owner == $p, age > 30 ) from $p.pets[0]<br>
<br>
Again if the nested objects are inserted as MOGs, the joins would be
obeyed instead of using 'from', i.e. they'll receive notifications
from nested object update.<br>
<br>
This is partly why I think we need to have a think about syntax
accessors in general, before we decide what to do, there are a lot
of related areas and a decision in one area impacts another.<br>
<br>
Mark<br>
<br>
<br>
<blockquote
cite="mid:1311958227.3376.YahooMailClassic@web81505.mail.mud.yahoo.com"
type="cite">
<table border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
<td style="font: inherit;" valign="top"><br>
--- On <b>Fri, 7/29/11, Mark Proctor <i><a class="moz-txt-link-rfc2396E" href="mailto:mproctor@codehaus.org"><mproctor@codehaus.org></a></i></b>
wrote:<br>
<blockquote style="border-left: 2px solid rgb(16, 16,
255); margin-left: 5px; padding-left: 5px;"><br>
From: Mark Proctor <a class="moz-txt-link-rfc2396E" href="mailto:mproctor@codehaus.org"><mproctor@codehaus.org></a><br>
Subject: Re: [rules-users] Condition syntax to access
Map<br>
To: <a class="moz-txt-link-abbreviated" href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
Date: Friday, July 29, 2011, 8:52 AM<br>
<br>
<div id="yiv1280163465"> On 29/07/2011 14:28, Edson
Tirelli wrote:
<blockquote 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>
<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 type="cite">
<div>
<div><br>
</div>
<div> Edson</div>
<div><br>
</div>
<br>
<div class="yiv1280163465gmail_quote">2011/7/29
Mark Proctor <span dir="ltr"><<a
moz-do-not-send="true" rel="nofollow"
ymailto="mailto:mproctor@codehaus.org"
target="_blank"
href="/mc/compose?to=mproctor@codehaus.org">mproctor@codehaus.org</a>></span><br>
<blockquote class="yiv1280163465gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex;">
<div> 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="yiv1280163465im"><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"
rel="nofollow"
ymailto="mailto:ed.tirelli@gmail.com"
target="_blank"
href="/mc/compose?to=ed.tirelli@gmail.com">ed.tirelli@gmail.com</a>></span><br>
<div class="yiv1280163465gmail_quote">
<blockquote
class="yiv1280163465gmail_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="yiv1280163465h5"><br>
<br>
<br>
<blockquote type="cite">
<div class="yiv1280163465gmail_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="yiv1280163465gmail_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="yiv1280163465gmail_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="yiv1280163465gmail_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="yiv1280163465gmail_quote">2011/7/28
Vincent LEGENDRE <span
dir="ltr"><<a
moz-do-not-send="true"
rel="nofollow"
ymailto="mailto:vincent.legendre@eurodecision.com"
target="_blank"
href="/mc/compose?to=vincent.legendre@eurodecision.com">vincent.legendre@eurodecision.com</a>></span><br>
<blockquote
class="yiv1280163465gmail_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"
rel="nofollow"
ymailto="mailto:rules-users@lists.jboss.org"
target="_blank"
href="/mc/compose?to=rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<a moz-do-not-send="true"
rel="nofollow"
target="_blank"
href="https://lists.jboss.org/mailman/listinfo/rules-users">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"
rel="nofollow" target="_blank"
href="http://www.jboss.com">www.jboss.com</a><br>
</font><br>
_______________________________________________<br>
rules-users mailing list<br>
<a moz-do-not-send="true"
rel="nofollow"
ymailto="mailto:rules-users@lists.jboss.org"
target="_blank"
href="/mc/compose?to=rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<a moz-do-not-send="true"
rel="nofollow" target="_blank"
href="https://lists.jboss.org/mailman/listinfo/rules-users">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" rel="nofollow" ymailto="mailto:rules-users@lists.jboss.org" target="_blank" href="/mc/compose?to=rules-users@lists.jboss.org">rules-users@lists.jboss.org</a>
<a moz-do-not-send="true" rel="nofollow" target="_blank" href="https://lists.jboss.org/mailman/listinfo/rules-users">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" rel="nofollow"
ymailto="mailto:rules-users@lists.jboss.org"
target="_blank"
href="/mc/compose?to=rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<a moz-do-not-send="true" rel="nofollow"
target="_blank"
href="https://lists.jboss.org/mailman/listinfo/rules-users">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"
rel="nofollow" target="_blank"
href="http://www.jboss.com">www.jboss.com</a><br>
</div>
<br>
<fieldset class="yiv1280163465mimeAttachmentHeader"></fieldset>
<br>
<pre>_______________________________________________
rules-users mailing list
<a moz-do-not-send="true" rel="nofollow" class="yiv1280163465moz-txt-link-abbreviated" ymailto="mailto:rules-users@lists.jboss.org" target="_blank" href="/mc/compose?to=rules-users@lists.jboss.org">rules-users@lists.jboss.org</a>
<a moz-do-not-send="true" rel="nofollow" class="yiv1280163465moz-txt-link-freetext" target="_blank" href="https://lists.jboss.org/mailman/listinfo/rules-users">https://lists.jboss.org/mailman/listinfo/rules-users</a>
</pre>
</blockquote>
<br>
</div>
<br>
-----Inline Attachment Follows-----<br>
<br>
<div class="plainMail">_______________________________________________<br>
rules-users mailing list<br>
<a moz-do-not-send="true"
ymailto="mailto:rules-users@lists.jboss.org"
href="/mc/compose?to=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>
</div>
</blockquote>
</td>
</tr>
</tbody>
</table>
<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>