I'd vote for something based upon the *Modfy choices - I think they are far clearer that they have something to do with drools than the PropertySpecific which could easily belong to Spring, JPA, BeanXYZ or a whole host of other technologies!
Thomas > -----Original Message----- > From: rules-dev-boun...@lists.jboss.org [mailto:rules-dev- > boun...@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.fu...@gmail.com> 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@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 postmas...@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev
