We are just fine tuning PropertySpecific behahviour. Initially a pattern without any properties' mask was set to LONG.MAX_VALUE so that it responded to any field changes. However we've now changed it to 0, so Cell() will respond to the initial insertion, but it will not respond to any modifies. Should you want it to respond to modifies you must add @watch(*). The other aspect is that we are adding a kbuillder configration to set the default behaviour. Currently it is off. With it defaulting to off using PropertySpecific as an annotation makes sense. If we default it to on you then need to use PropertySpecific(true). i.e. the reversing of the logic means for the common case we now need an argument. Considering this common case will become default at some point in the future, i.e. you want the parameterless version to be the common use case. NonPropertySpecific is a bit long :) Mark _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

If you're referring to the discussion about the annotation's names, we haven't taken a decision yet, but it is something that needs to be addressed next week latest. At the moment I committed my code using the annotations @PropertySpecific and @NotPropertySpecific but nobody like them (including myself) so I will rename them as soon as we will take a decision.

Mario On Thu, Feb 16, 2012 at 6:35 PM, Wolfgang Laun <wolfgang.laun(a)gmail.com <mailto:wolfgang.laun@gmail.com>> wrote: There was a brief discussion about annotation class names a few days ago - has this been finalized, and if so, what is the result? Thanks Wolfgang On 16 February 2012 18:26, Mark Proctor <mproctor(a)codehaus.org <mailto:mproctor@codehaus.org>> wrote: We are just fine tuning PropertySpecific behahviour. Initially a pattern without any properties' mask was set to LONG.MAX_VALUE so that it responded to any field changes. However we've now changed it to 0, so Cell() will respond to the initial insertion, but it will not respond to any modifies. Should you want it to respond to modifies you must add @watch(*). The other aspect is that we are adding a kbuillder configration to set the default behaviour. Currently it is off. With it defaulting to off using PropertySpecific as an annotation makes sense. If we default it to on you then need to use PropertySpecific(true). i.e. the reversing of the logic means for the common case we now need an argument. Considering this common case will become default at some point in the future, i.e. you want the parameterless version to be the common use case. NonPropertySpecific is a bit long :) 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 _______________________________________________ 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

Big fix just went in for property specific. Mask calculation is now fully determined at network build time, and not runtime. Much greater test coverage for various network build configurations. Lots of edge cases are now fixed as a result of increased tests, and also ability to test at build time, rather runtime. Rule removal is now supported and masks will be recalculated. https://github.com/droolsjbpm/drools/commit/5dad95a82ee462965c8b79fcf66e7... https://github.com/droolsjbpm/drools/blob/master/drools-compiler/src/test... Cell() Will not listen to any changes without adding an a @watch; i.e. a pattern without any constraints is equivalent to @watch(!*) With regards to @PropertySpecific. I'm now leaning towards the following two: ClassListener PropertyListener Which is short for: ClassChangeListener PropertyChangeListener I don't think we need the longer version as it should be pretty clear what the shorter versions are. The names are very generic, so we just need to be sure they don't clash with other potential annotations. The above two require no attributes, but must be used exclusively. The alternative is: ChangeListener(Property) ChangeListener(Class) Mark On 16/02/2012 18:32, Mark Proctor wrote: > On 16/02/2012 17:43, Mario Fusco wrote: >> If you're referring to the discussion about the annotation's names, >> we haven't taken a decision yet, but it is something that needs to be >> addressed next week latest. >> At the moment I committed my code using the annotations >> @PropertySpecific and @NotPropertySpecific but nobody like them >> (including myself) so I will rename them as soon as we will take a >> decision. > yup, we are struggling to find something that is consistent and > doesn't look pants :( > > So far we just keep coming back to PropertySpecific, which is ok for > now. But once we reverse the behaviour with the common use case > becoming PropertySpecific(false) we lose a little bit of language > ergenomics imho. Btw I say common use case, because PropertySpecific > with no arguments won't be useful as that will be the default > behaviour at that point. > > Mark >> >> Mario >> >> On Thu, Feb 16, 2012 at 6:35 PM, Wolfgang Laun >> <wolfgang.laun(a)gmail.com <mailto:wolfgang.laun@gmail.com>> wrote: >> >> There was a brief discussion about annotation class names a few days >> ago - has this been finalized, and if so, what is the result? >> >> Thanks >> Wolfgang >> >> >> On 16 February 2012 18:26, Mark Proctor <mproctor(a)codehaus.org >> <mailto:mproctor@codehaus.org>> wrote: >> >> We are just fine tuning PropertySpecific behahviour. >> >> Initially a pattern without any properties' mask was set to >> LONG.MAX_VALUE so that it responded to any field changes. >> >> However we've now changed it to 0, so Cell() will respond to >> the initial >> insertion, but it will not respond to any modifies. >> >> Should you want it to respond to modifies you must add @watch(*). >> >> The other aspect is that we are adding a kbuillder >> configration to set >> the default behaviour. Currently it is off. With it >> defaulting to off >> using PropertySpecific as an annotation makes sense. If we >> default it to >> on you then need to use PropertySpecific(true). i.e. the >> reversing of >> the logic means for the common case we now need an argument. >> Considering >> this common case will become default at some point in the >> future, i.e. >> you want the parameterless version to be the common use case. >> NonPropertySpecific is a bit long :) >> >> 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 >> >> >> >> _______________________________________________ >> 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 >