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(a)lists.jboss.org [mailto: rules-dev-bounces(a)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(a)codehaus.org&gt; 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/ca55c78429cbc0f14167c604c413cdc... 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/d... 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(a)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(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

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(a)nds.com <mailto:TSwindells@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@lists.jboss.org <mailto:rules-dev-bounces@lists.jboss.org> [mailto:rules-dev-bounces@lists.jboss.org <mailto:rules-dev-bounces@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(a)codehaus.org <mailto:mproctor@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/ca55c78429cbc0f14167c604c413cdc... 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/d... 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(a)lists.jboss.org <mailto:rules-dev@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(a)nds.com <mailto:postmaster@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(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/rules-dev _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

Hi all, just a quick recap of what I did until now to check if we are all on the same page and also agree with the naming convention I used. The property specific feature is off by default in order to make the behavior of the rule engine backward compatible with the former releases. If you want to activate it on a specific bean you have to annotate it with @propSpecific. This annotation works both on drl type declarations: declare Person @propSpecific firstName : String lastName : String end and on Java classes: @PropSpecific public static class Person { private String firstName; private String lastName; } Moreover on Java classes you can also annotate any method to say that its invocation actually modifies other properties. For instance in the former Person class you could have a method like: @Modifies( "firstName, lastName" ) public void setName(String name) { String[] names = name.split("\\s"); this.firstName = names[0]; this.lastName = names[1]; } That means that if a rule has a RHS like the following: modify($person) { setName("Mario Fusco") } it will correctly recognize that both the firstName and lastName have been modified and act accordingly. Of course the @Modifies annotation on a method has no effect if the declaring class isn't annotated with @PropSpecific. The third annotation I have introduced is on patterns and allows you to modify the inferred set of properties "listened" by it. So, for example, you can annotate a pattern in the LHS of a rule like: Person( firstName == $expectedFirstName ) @watch( lastName ) // --> listens for changes on both firstName (inferred) and lastName Person( firstName == $expectedFirstName ) @watch( * ) // --> listens for all the properties of the Person bean Person( firstName == $expectedFirstName ) @watch( lastName, !firstName ) // --> listens for changes on lastName and explicitly exclude firstName Person( firstName == $expectedFirstName ) @watch( *, !age ) // --> listens for changes on all the properties except the age one Once again this annotation has no effect if the corresponding pattern's type hasn't been annotated with @PropSpecific. I've almost finished with the development of this feature (at the moment I am missing the compile-time check of the properties named in the @watch annotation together with some more exhaustive tests), so if you think that I misunderstood something or there is room for any improvement (or you just don't like the annotation's names I chose) please let me know as soon as possible. Mario _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

The property specific feature is off by default in order to make the behavior of the rule engine backward compatible with the former releases. If you want to activate it on a specific bean you have to annotate it with @propSpecific.

This annotation works both on drl type declarations: declare Person @propSpecific firstName : String lastName : String end and on Java classes: @PropSpecific public static class Person { private String firstName; private String lastName; } Moreover on Java classes you can also annotate any method to say that its invocation actually modifies other properties. For instance in the former Person class you could have a method like: @Modifies( "firstName, lastName" ) public void setName(String name) { String[] names = name.split("\\s"); this.firstName = names[0]; this.lastName = names[1]; }

That means that if a rule has a RHS like the following: modify($person) { setName("Mario Fusco") } it will correctly recognize that both the firstName and lastName have been modified and act accordingly. Of course the @Modifies annotation on a method has no effect if the declaring class isn't annotated with @PropSpecific. The third annotation I have introduced is on patterns and allows you to modify the inferred set of properties "listened" by it. So, for example, you can annotate a pattern in the LHS of a rule like: Person( firstName == $expectedFirstName ) @watch( lastName ) // --> listens for changes on both firstName (inferred) and lastName Person( firstName == $expectedFirstName ) @watch( * ) // --> listens for all the properties of the Person bean Person( firstName == $expectedFirstName ) @watch( lastName, !firstName ) // --> listens for changes on lastName and explicitly exclude firstName Person( firstName == $expectedFirstName ) @watch( *, !age ) // --> listens for changes on all the properties except the age one

Once again this annotation has no effect if the corresponding pattern's type hasn't been annotated with @PropSpecific.

On 18/01/2012, Geoffrey De Smet&lt;ge0ffrey.spam(a)gmail.com&gt; wrote: > throw new IllegalStateException("The factClass (" + factClass + ") > has a property (" + property + ") that has a @Modifies annotation, but > the class isn't annotated with @PropSpecific."); Use less words: "In class (" + factClass + ") property (" + property + ") is annotated with @Modifies, but the class isn't annotated with @PropSpecific."

However, there's a good case for permitting this: testing to try both ways, to track down a (user) bug,... Commenting out @PropSpecific is just like turning off the main switch. If you get errors, you'll have to mess with all the @Modifies, too.

> 2) @Modifies( "firstName, lastName" ) should not put the comma (,) > inside the quotes. Go for: > @Modifies( "firstName", "lastName" ) Then it must be: @Modifies( { "firstName", "lastName" } )

> 3) What's the point of doing a @PropSpecific on a field instead of a class? >> declare Person >> @propSpecific >> firstName : String The answer is: DRL syntax requires it this way.

Cheers Wolfgang _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

From: Geoffrey De Smet <ge0ffrey.spam(a)gmail.com&gt;

>>     throw new IllegalStateException("The factClass (" + factClass + ") >> has a property (" + property + ") that has a @Modifies annotation, but >> the class isn't annotated with @PropSpecific."); > Use less words: > "In class (" + factClass + ") property (" + property + ") is annotated > with @Modifies, but the class isn't annotated with @PropSpecific." +1 > However, there's a good case for permitting this: testing to try both > ways, to track down a (user) bug,... Commenting out @PropSpecific is > just like turning off the main switch. If you get errors, you'll have > to mess with all the @Modifies, too. -1 The other case, where a user adds @Modifies but forgets to add @PropSpecific and then sees in production that drools doesn't behave as expected (it just ignores the @Modifies) is worse imo.

-----Original Message----- From: rules-dev-bounces(a)lists.jboss.org [mailto:rules-dev- bounces(a)lists.jboss.org] On Behalf Of Wolfgang Laun Sent: 07 February 2012 10:57 To: Rules Dev List Subject: Re: [rules-dev] Fine Grained Property Change Listeners (Slot Specific) Nice going, Mario. Re: Annotation names. I've consulted http://www.synonym.com/antonym @PropertySpecific, @PropertyGeneral @PropertySensitive, @PropertyInsensitive @SelectiveModify, @InclusiveModify @MaskedModify, @FullModify Re: Person(this==$foo) I have a strong argument against making a distinction between a Java Bean and a DRL-declared type. It may happen that you migrate (for whatever reason) a DRL type to a Java class - and then what? Re: Person() What if some following pattern refers to the matched Person via a variable bound to Person(), e.g., $p: Person() $c: Car( ownerName == $p.name ) (Just being curious: What about the sign bit - the full 64-bit mask would be Long.MIN_VALUE?) Cheers Wolfgang On 07/02/2012, Mario Fusco <mario.fusco(a)gmail.com&gt; wrote: > Hi all, > > I just added the possibility to enable/disable PropertySpecific as on > option inside the KnowledgeBuilderConfiguration. In particular this > new PropertySpecificOption can have 3 values at the moment: > > - DISABLED => the feature is turned off and all the other related > annotations are just ignored > - ALLOWED => this is the default behavior: types are not property > specific unless they are not annotated with @PropertySpecific > - ALWAYS => all types are property specific by default > > While using this last option you may want sometimes to make a > particular type not property specific. My first thought to allow that > was to add a boolean argument to the @PropertySpecific annotation so > you could write > @PropertySpecific(true) (or just @PropertySpecific since true would be > the default value) when you want to make a type property specific > while using the ALLOWED option (or no option at all) and > @PropertySpecific(false) when you want a type not being property specific while using the option ALWAYS. > > As pointed out by Mark this would have the unpleasant side effect that > the default value for @PropertySpecific is actually the unwanted (and > useless) one while using the ALWAYS option. For this reason, instead > of adding a boolean argument to @PropertySpecific, I introduced a > second annotation @NotPropertySpecific having the meaning of > @PropertySpecific(false). To be honest I am not very happy with this > last name so I am looking for a better name for the > @PropertySpecific/@NotPropertySpecific pair. Other possibilities could > be: @Watchable/@Unwatchable and @Fine/@Coarse but I cannot decide > between them. Any preference or even better any good alternative idea? > > On a different note, I have a few doubts on how to infer the bit mask > of the watched properties of a type for 2 specific patterns: > > 1. Person ( this == $child.father ) > at the moment while pattern matching on 'this' the Long.MAX_VALUE mask > (meaning watch for changes on ALL the type's properties) is inferred. > Despite this choice is not formally wrong, probably it could be > refined a bit more. In reality I don't think I could do something > different if Person is a JavaBean, but if it is defined as a type > declaration in the DRL maybe I could watch only the properties annotated with @key (if any). Any thought? > > 2. Person ( ) > currently also in this case the inferred mask is Long.MAX_VALUE. I am > not sure this is neither the correct behavior nor the most intuitive > one, but in this case I cannot think to a better strategy. Any suggestion? > > Thanks for your feedback, > Mario > _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev