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

Mon Jan 16 09:51:14 EST 2012

An absolutely watertight and foolproof system would know which attributes
(or getter methods) change due to which setter method calls (and, beyond
that, whether the setter really *changes *the value). This, and only this,
would be the summit of "fidelity".

Anything else is an approximation, and, depending on the measure you apply,
one procedure may be better than another one. Missing a change is more
difficult to circumvent with legacy techniques than it is to avoid spurious
firings.

Given that the aforementioned analysis is extremely difficult, it is
obvious that a truly high-fidelity reaction to changes can't be done
without users providing dependency information by means of annotations or
some similar technique

-W

On 16 January 2012 14:46, Swindells, Thomas <TSwindells at nds.com> 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.****
>
> ** **
>
> 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> 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
> 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/a45dbbf4/attachment-0001.html 