[rules-dev] PropertySpecific Update

[Wolfgang Laun]

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 <mproctor at codehaus.org> 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
>>> <wolfgang.laun at gmail.com <mailto:wolfgang.laun at 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 at codehaus.org
>>>     <mailto:mproctor at 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 at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>>>         https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>>
>>>
>>>     _______________________________________________
>>>     rules-dev mailing list
>>>     rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>>>     https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>
>