[rules-users] Condition syntax to access Map

[Wolfgang Laun]

2011/7/31 Mark Proctor <mproctor at codehaus.org>

>  On 31/07/2011 19:39, Wolfgang Laun wrote:
>
> 2011/7/31 Mark Proctor <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.

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.


>
> 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.

-W


>
> Mark
>
>
> -W
>
>
> _______________________________________________
> rules-users mailing listrules-users at lists.jboss.orghttps://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/def7a37a/attachment.html