[rules-dev] Fine Grained Property Change Listeners (Slot Specific)

[Mark Proctor]

On 17/01/2012 21:00, Edson Tirelli wrote:
>
>    Nicely done sir! :)
>
>    My only comments are very minor...
>
> * I think we should keep the property names consistent between the 
> java and the declare element, so I suggest you use uppercase for both 
> (@PropSpecific).
it's kept with how we have the other annotations on type declarations, 
all of which allow lower case at the moment.
@role
@format
@position
> * I think @onChange is more meaningful to me than @watch, but that is 
> just my opinion.
>
we can have a wider vote. I was bit uncomfortable with onChange, because 
it could mean other things. Watch was shorter and I think more accurate. 
"Just watch these properties". onChange sounds like we should be 
attaching some callback, for an event that has happened.

>    On the pattern annotation, how is the EBNF now?
>
> lhsPattern := QUESTION? qualifiedIdentifier LEFT_PAREN 
> positionalConstraints? constraints? RIGHT_PAREN annotation* (OVER 
> patternFilter)? (FROM patternSource)?
>
>    Thanks,
>        Edson
>
> On Tue, Jan 17, 2012 at 2:20 PM, Mario Fusco <mario.fusco at gmail.com 
> <mailto:mario.fusco at gmail.com>> wrote:
>
>     Hi all,
>
>     just a quick recap of what I did until now to check if we are all
>     on the same page and also agree with the naming convention I used.
>
>     The property specific feature is off by default in order to make
>     the behavior of the rule engine backward compatible with the
>     former releases. If you want to activate it on a specific bean you
>     have to annotate it with @propSpecific. This annotation works both
>     on drl type declarations:
>
>     declare Person
>         @propSpecific
>         firstName : String
>         lastName : String
>     end
>
>     and on Java classes:
>
>     @PropSpecific
>     public static class Person {
>         private String firstName;
>         private String lastName;
>     }
>
>     Moreover on Java classes you can also annotate any method to say
>     that its invocation actually modifies other properties. For
>     instance in the former Person class you could have a method like:
>
>     @Modifies( "firstName, lastName" )
>     public void setName(String name) {
>         String[] names = name.split("\\s");
>         this.firstName = names[0];
>         this.lastName = names[1];
>     }
>
>     That means that if a rule has a RHS like the following:
>
>     modify($person) { setName("Mario Fusco") }
>
>     it will correctly recognize that both the firstName and lastName
>     have been modified and act accordingly. Of course the @Modifies
>     annotation on a method has no effect if the declaring class isn't 
>     annotated with @PropSpecific.
>
>     The third annotation I have introduced is on patterns and allows
>     you to modify the inferred set of properties "listened" by it. So,
>     for example, you can annotate a pattern in the LHS of a rule like:
>
>     Person( firstName == $expectedFirstName ) @watch( lastName ) //
>     --> listens for changes on both firstName (inferred) and lastName
>     Person( firstName == $expectedFirstName ) @watch( * ) // -->
>     listens for all the properties of the Person bean
>     Person( firstName == $expectedFirstName ) @watch( lastName,
>     !firstName ) // --> listens for changes on lastName and explicitly
>     exclude firstName
>     Person( firstName == $expectedFirstName ) @watch( *, !age ) // -->
>     listens for changes on all the properties except the age one
>
>     Once again this annotation has no effect if the corresponding
>     pattern's type hasn't been annotated with @PropSpecific.
>
>     I've almost finished with the development of this feature (at the
>     moment I am missing the compile-time check of the properties named
>     in the @watch annotation together with some more exhaustive
>     tests), so if you think that I misunderstood something or there is
>     room for any improvement (or you just don't like the annotation's
>     names I chose) please let me know as soon as possible.
>
>     Mario
>
>     _______________________________________________
>     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
>
>
>
>
> -- 
>   Edson Tirelli
>   JBoss Drools Core Development
>   JBoss by Red Hat @ www.jboss.com <http://www.jboss.com>
>
>
> _______________________________________________
> 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/20120118/b808e9df/attachment-0001.html