[rules-users] Condition syntax to access Map

[Mark Proctor]

On 02/08/2011 07:15, Wolfgang Laun wrote:
> 2011/7/31 Mark Proctor <mproctor at codehaus.org 
> <mailto:mproctor at codehaus.org>>
>
>     On 31/07/2011 19:39, Wolfgang Laun wrote:
>>     2011/7/31 Mark Proctor <mproctor at codehaus.org
>>     <mailto:mproctor at codehaus.org>>
>>
>>
>>
>>         Implicit mapping I call Managed Object Graphs MOGs. So you
>>         can write
>>         Person( address.street == "my road" )
>>
>>         And that internally would get translated too
>>         $p : Person()
>>         Address( person == $p, street == "my road" )
>>
>>         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.
>>
>>
>>     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...
>     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.
>
>
> 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.
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.
>
> The LHS
>    Person(...)
> alone fires due a Person inserted and not when an Address is inserted; 
> it fires again if a Person() update is signalled. In contrast,
>    Person()
>    Address(...)
> fires after both have been inserted and again after /either one/ has 
> been updated.
>
>     Something can't be inserted anyway unless it has the necessary
>     references for the joins.
>
>
> This "references" I doubt very much. Surely you can "insert" anything. 
> And joins are possible on (primary key attributes as well.
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?
>
>
>     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.
>
>
> 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:
>
> declare Person
>    name : String  # default implementation as "JBean field"
>    props  : Map
>    address : Address as props["addr"]  # the implementation
> end
>
> declare Address
>    lines : String[]
>    street : String as lines[1]
> end
>
> Person(  name == "Psmith", address/street == "Main Drag"  )
> Car( owner/address/street ... )  # Person owner
>
> Notice that explicitly using
>    props["addr"]
> or
>    lines[1]
> 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.
>
> Also, notice that a "navigation expression" could be dynamic, making 
> navigation dependent on the object's state, or whatever.
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.

Mark
>
> -W
>
>
>     Mark
>>
>>     -W
>>
>>
>>     _______________________________________________
>>     rules-users mailing list
>>     rules-users at lists.jboss.org  <mailto:rules-users at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>     _______________________________________________
>     rules-users mailing list
>     rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20110802/53849196/attachment.html