Isn't "Listener" used as a generic term for a class that's to be informed when something happens? But the proposed annotations do not denote listeners; rather they belong to entities that must be heard or observed.
Here's yet another one: @ClassReactive @PropertyReactive Cheers Wolfgang On 27/02/2012, Mark Proctor <[email protected]> wrote: > 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/5dad95a82ee462965c8b79fcf66e76e39ecf56f2 > https://github.com/droolsjbpm/drools/blob/master/drools-compiler/src/test/java/org/drools/integrationtests/PropertySpecificTest.java > > 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 >>> <[email protected] <mailto:[email protected]>> 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 <[email protected] >>> <mailto:[email protected]>> 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 >>> [email protected] <mailto:[email protected]> >>> https://lists.jboss.org/mailman/listinfo/rules-dev >>> >>> >>> >>> _______________________________________________ >>> rules-dev mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.jboss.org/mailman/listinfo/rules-dev >>> >>> >>> >>> >>> _______________________________________________ >>> rules-dev mailing list >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/rules-dev >> > > _______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
