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

[Mark Proctor]

On 14/01/2012 08:59, Wolfgang Laun wrote:
> 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".
Edson has gone off dash, due to difficulties in the parser where it'll 
be treated as an arithmatic expression unless it's made a hard keyword. 
Personally I like dash as it's more readable. We will likely go with 
property specific, either prop-specific of propSpecific.
>
> Is this new feature in some way configurable for the KnowledgeBase?
Not at the moment, but it will be for beta2 next week. If we were 
starting again, we'd probably have it on by default. But as it changes 
the engine behaviour it has to be configured off. You'll annotate the 
type declaration to turn it on, per class.

As per the blog article, we also still want to add the @change 
annotation to allow additional fine tuning of what the pattern does or 
does not listen too.
> 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
For any nested accessor use, it'll notify the engine of hte top level 
field, i..e. address.city.name will result in an notification of 
"address" on the parent object. In the above example the property "list" 
will be notified.

For fake setters, that end up setting multiple fields, we'll allow 
annotations - still need an annotation name. i.e. setName() would  
actually update firstName and lastName, so we'll need an annotation on 
name that references those two fields to build the mask.


>
> Wolfgang
>
> PS: The new feature is actually /restricting the sensitivity of the 
> system./
> Therefore, I feel that "high-fidelity" is actually counter-intuitive!
Name is far too verbose, and was a bit of fun, but it is correct. 
""high-fidelity equipment has minimal amounts of noise 
<http://en.wikipedia.org/wiki/Noise> and distortion 
<http://en.wikipedia.org/wiki/Distortion> and an accurate frequency 
response <http://en.wikipedia.org/wiki/Frequency_response>."" Slot 
specific is allowing you to remove the noise and distortion, i..e 
removing the fields you don't care about, as they are just noise.
>
>
> 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
>
>
>
>
> _______________________________________________
> 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/20120114/9c2c40f5/attachment.html