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.l...@gmail.com <mailto:wolfgang.l...@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 <mproc...@codehaus.org
    <mailto:mproc...@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@lists.jboss.org <mailto:rules-dev@lists.jboss.org>
        https://lists.jboss.org/mailman/listinfo/rules-dev



    _______________________________________________
    rules-dev mailing list
    rules-dev@lists.jboss.org <mailto:rules-dev@lists.jboss.org>
    https://lists.jboss.org/mailman/listinfo/rules-dev




_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

Reply via email to