[rules-dev] Fine Grained Property Change Listeners (Slot Specific)
Mark Proctor
mproctor at codehaus.org
Mon Jan 16 14:30:07 EST 2012
"(and, beyond that, whether the setter really /changes /the value)."
That's actually a feature I want to add, just not sure of the syntax and
behaviour. In short it should allow a pattern to match on the either of
the rising or falling edges of a match, i.e. it'll only propagate when
the pattern first matches, further rematches will not propagate unless
it is first unmatched (made false). A falling edge would only propagate
and match when the pattern no longer matches, i.e. stops being true.
There is some difficult with the behaviour on retraction, as you
potentially have a handle an object no longer in the working memory.
Anyway worth thinking on, as it would make a nice 5.5 feature later this
year :)
Mark
On 16/01/2012 14:51, Wolfgang Laun wrote:
> 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
> <mailto: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>
> [mailto: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 <mailto: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 <mailto:rules-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
> _______________________________________________
> 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/fbd5f2e6/attachment-0001.html
More information about the rules-dev
mailing list