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