2011/7/31 Mark Proctor <span dir="ltr"><<a 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></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 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><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>
<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. 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>
<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 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>
</div></blockquote>
<br>
</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>