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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
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
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
