<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 02/08/2011 07:15, Wolfgang Laun wrote:
<blockquote
cite="mid:CANaj1LeFFY5tLn2Y8O2tgfiUry_wSrNNS7bDyyaZOSx-HaLDnA@mail.gmail.com"
type="cite">2011/7/31 Mark Proctor <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:mproctor@codehaus.org">mproctor@codehaus.org</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;">
<div bgcolor="#FFFFFF" text="#000000">
<div>
<div class="h5"> On 31/07/2011 19:39, Wolfgang Laun wrote:
<blockquote type="cite">2011/7/31 Mark Proctor <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:mproctor@codehaus.org"
target="_blank">mproctor@codehaus.org</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;">
<div bgcolor="#FFFFFF" text="#000000"> <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>
</div>
</blockquote>
<div><br>
So what if Address is not an inserted fact? So
far, a CE with type Foo(...) implied the existence
of a fact of that type. I'm not sure that
inserting some object should imply the insertion
of all of its descendants as facts as well...<br>
</div>
</div>
</blockquote>
</div>
</div>
You don't necessarily have to insert Address. It can attach
a listener, assuming the pojo supported it, when it's
accessed in a pattern - allowing the pattern to receive
updates from nested objects.<br>
</div>
</blockquote>
<div><br>
Surely you mean that changes to Address should result in an
update notification for the owning Person object. - But that's
not what I meant. <br>
</div>
</div>
</blockquote>
When the expression is evaluated we could detect that Address is not
inserted and attach a listener to that specific instance, so we can
receive updates for it. So for that rule it would work the same as
Person() Address() yet Address was never inserted. Note that it
would be a lightweight listener just for that join, and not a global
insertion. It could be possible to global insert something too "on
demand", but we'd need something annotation driven to allow the user
to specify their intent.<br>
<blockquote
cite="mid:CANaj1LeFFY5tLn2Y8O2tgfiUry_wSrNNS7bDyyaZOSx-HaLDnA@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div><br>
The LHS<br>
Person(...)<br>
alone fires due a Person inserted and not when an Address is
inserted; it fires again if a Person() update is signalled. In
contrast,<br>
Person() <br>
Address(...)<br>
fires after both have been inserted and again after <i>either
one</i> has been updated.<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 bgcolor="#FFFFFF" text="#000000">Something can't be
inserted anyway unless it has the necessary references for
the joins.<br>
</div>
</blockquote>
<div><br>
This "references" I doubt very much. Surely you can "insert"
anything. And joins are possible on (primary key attributes as
well.<br>
</div>
</div>
</blockquote>
In the case of above Person already has a refernce to Address, so
that can be used. But how do you do a one to many relationship
without correct references?
<blockquote
cite="mid:CANaj1LeFFY5tLn2Y8O2tgfiUry_wSrNNS7bDyyaZOSx-HaLDnA@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="border-left: 1px solid
rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left:
1ex;">
<div bgcolor="#FFFFFF" text="#000000"> <br>
I want to look at a full range of MOGs to automate and
semi-autimate things with regards to nested structures. At
the moment there is no best practice and DRL (or any other
rule language) does not make this nice. We ALL suck for
compact nested accessors.<br>
</div>
</blockquote>
<div><br>
The notation a.b.c reflects an implementation technique for a
hierarchical data type. (Traditionally, x-dot-y means "add the
offset for y to the address resulting from x".) A more general
concept for "navigation" in a data structure would have to
separate a logical relationship from the implementation
technique. It may be necessary to retain the "dot" notation
for the hard coded access and to devise an entirely new
notation for logical navigation.</div>
</div>
</blockquote>
<blockquote
cite="mid:CANaj1LeFFY5tLn2Y8O2tgfiUry_wSrNNS7bDyyaZOSx-HaLDnA@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div> As a somewhat contrived example, assume that Address is
stored as a map field with key "addr" and the street is the
second text line of the address: <br>
<br>
declare Person<br>
name : String # default implementation as "JBean field" <br>
props : Map<br>
address : Address as props["addr"] # the implementation<br>
end<br>
<br>
declare Address<br>
lines : String[]<br>
street : String as lines[1]<br>
end<br>
<br>
Person( name == "Psmith", address/street == "Main Drag" )<br>
Car( owner/address/street ... ) # Person owner<br>
<br>
Notice that explicitly using<br>
props["addr"]<br>
or<br>
lines[1]<br>
is just another implementation dependent notation which breaks
as soon as someone decides to change it in the class. Such
things should not permeate application code.<br>
<br>
Also, notice that a "navigation expression" could be dynamic,
making navigation dependent on the object's state, or
whatever.<br>
</div>
</div>
</blockquote>
MOGs could indeed use a different / operator to indicate that they
are relational and to be treated as joins. when we come to
implementing this, we'll have a wider debate on dev mailing list, as
it's not happening in the next few weeks :) Just trying to give
people a taste of directions we can go to improve things.<br>
<br>
Mark<br>
<blockquote
cite="mid:CANaj1LeFFY5tLn2Y8O2tgfiUry_wSrNNS7bDyyaZOSx-HaLDnA@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>
<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 bgcolor="#FFFFFF" text="#000000"> <br>
Mark<br>
<blockquote type="cite">
<div class="gmail_quote">
<div> <br>
-W<br>
</div>
</div>
<div class="im"> <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>
</div>
</blockquote>
<br>
</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>
<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>