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

-----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