[rules-dev] Fine Grained Property Change Listeners (Slot Specific)

Mon Jan 16 14:24:41 EST 2012

On 16/01/2012 13:46, Swindells, Thomas wrote:
>
> The change is reducing the coarseness of the system and so making it 
> more sensitive to the scope of the change so I'd say high fidelity is 
> the correct term.
>
> I agree with you I'm concerned how this works with non-pure java beans 
> where some of the setters may update multiple fields, or there may be 
> none bean methods like a reset() method -- I don't understand how 
> these would interact in the system, is there a mechanism to explicitly 
> invalidate a property or mark the whole lot as dirty.
>
I think I replied to a later email on that. We will allow you to 
annotate a method with the list of names that refer to the fields it 
impacts, but it will only work on direct methods, not nested ones.

class Person
     String firstName
     String lastName

     @LinkedProperty("firstName", "lastName") // annotation name still 
to be decided
     public void setName() {
         ....

rule x when
     Person( name == "mark proctor" ) // will create a mask for name, 
firstName and lastName

Mark
>
> Thomas
>
> *From:*rules-dev-bounces at lists.jboss.org 
> [mailto:rules-dev-bounces at lists.jboss.org] *On Behalf Of *Wolfgang Laun
> *Sent:* 14 January 2012 08:59
> *To:* Rules Dev List
> *Subject:* Re: [rules-dev] Fine Grained Property Change Listeners 
> (Slot Specific)
>
> You really should follow naming conventions Java programmers are familiar
>
> with. javax.xml.bind.annotation.XmlAccessType, for instance, uses the
>
> term "member" for referring to "public getter/setter pairs", and this 
> comes
>
> close to what Drools does. Alternatively, there's "field" and "property",
>
> and I wouldn't worry about the extra lip mileage - you can always 
> abbreviate
>
> to "prop-specific".
>
> Is this new feature in some way configurable for the KnowledgeBase?
>
> There are fact types where modifying one member results in the change
>
> of more than one member. Consider the very plausible case:
>
>      $f: Fact(...)
>
>    then
>
>       modify( $f ){ getList().add( $x ) }
>
>    end
>
>    when
>
>      Fact( size > 10 )  # size implemented as getList().size()
>
>    then
>
> Wolfgang
>
> PS: The new feature is actually /restricting the sensitivity of the 
> system./
>
> Therefore, I feel that "high-fidelity" is actually counter-intuitive!
>
> On 13 January 2012 23:30, Mark Proctor <mproctor at codehaus.org 
> <mailto:mproctor at codehaus.org>> wrote:
>
> Mario just got a first cut working for fine grained property change
> listeners. Previously when you call update() it will trigger revaluation
> of all Patterns of the matching object type in the knowledeg base.
>
> As some have found this can be a problem, forcing you to split up your
> objects into smaller 1 to 1 objects, to avoid unwanted evaluation of
> objects - i.e. recursion or excessive evaluation problems.
>
> The new approach now means the pattern's will only react to fields
> constrained or bound inside of the pattern. This will help with
> performance and recursion and avoid artificial object splitting.  We
> previously discussed this here:
> http://blog.athico.com/2010/07/slot-specific-and-refraction.html
> You can see the unit test here:
> https://github.com/droolsjbpm/drools/blob/ca55c78429cbc0f14167c604c413cdc3faaf6988/drools-compiler/src/test/java/org/drools/integrationtests/MiscTest.java
>
> The implementation is bit mask based, so very efficient. When the engine
> executes a modify statement it uses a bit mask of fields being changed,
> the pattern will only respond if it has an overlapping bit mask. This
> does not work for update(), and is one of the reason why we promote
> modify() as it encapsulates the field changes within the statement. You
> can follow Mario's chain of work on this at his github activity feed:
> https://github.com/mariofusco.atom
>
> The adventerous amoung you can pick this up from hudson, or from maven,
> and start playing now. My hope is that this will make drools much easier
> to use:
> https://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/drools-distribution/target/
>
> Btw we are after a name. Drools is not a frame based system, so "slot
> specific" doesn't seem appropropriate. Property Specific seems a bit of
> a mouth full. I'm quite liking High Fidelity Change Listeners :) any
> other suggestions?
>
> slot-specific is the name used by Jess for this feature,
> http://www.jessrules.com/docs/71/constructs.html. It's also the standard
> way that Clips COOL works, which is the Clips OO module. Although that's
> partly a side effect of the triple representation of properties used in
> COOL, and the modifications are triple based. I don't know what
> mechanism Jess is using to enable this.
>
> Mark
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> ------------------------------------------------------------------------
>
> **************************************************************************************
> This message is confidential and intended only for the addressee. If 
> you have received this message in error, please immediately notify the 
> postmaster at nds.com and delete it from your system as well as any 
> copies. The content of e-mails as well as traffic data may be 
> monitored by NDS for employment and security purposes. To protect the 
> environment please do not print this e-mail unless necessary.
>
> NDS Limited. Registered Office: One London Road, Staines, Middlesex, 
> TW18 4EX, United Kingdom. A company registered in England and Wales. 
> Registered no. 3080780. VAT no. GB 603 8808 40-00
> **************************************************************************************
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20120116/040b978f/attachment.html