[rules-dev] Cell() PropertySpecific Behaviour

[Mark Proctor]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20120216/7e7ec59a/attachment.html