Hi Mario,
Here are a few suggestions
1) Fail fast in this case:
this annotation has no effect if the corresponding pattern's type
hasn't been annotated with @PropSpecific
Fail Fast with an exception like this:
throw new IllegalStateException("The factClass (" + factClass + ")
has a property (" + property + ") that has a @Modifies annotation, but
the class isn't annotated with @PropSpecific.");
If for a later version, we receive user input that there is actually a
good case where @Modifies exists without @PropSpecific, we can always
allow it (vica versa is not possible).
2) @Modifies( "firstName, lastName" ) should not put the comma (,)
inside the quotes. Go for:
@Modifies( "firstName", "lastName" )
or @ModifiesCombination( @Modifies("firstName"), @Modifies("lastName") )
The last way might look a bit strange, but it's a common practice, for
example in JPA-hibernate:
http://docs.jboss.org/hibernate/core/4.0/javadocs/org/hibernate/annotations/ColumnTransformers.html
http://docs.jboss.org/hibernate/core/4.0/javadocs/org/hibernate/annotations/ColumnTransformer.html
That last way won't break when there are additional properties on the
@Modifies annotations (while the other approaches will):
@ModifiesCombination( @Modifies("firstName", whenImplementsInterface
= FirstNameable.class), @Modifies("lastName", whenImplementsInterface =
LastNameable.class) )
3) What's the point of doing a @PropSpecific on a field instead of a class?
declare Person
@propSpecific
firstName : String
4) I also believe we should stick to Java naming conventions [1] as
close as possible because the main target audience to start using our
drools jars is the java programmers audience.
The stranger our stuff looks to them, the more likely they 'll try to
write "a simple solution" themselves instead of using our "complex"
framework.
4a) Like Edson says: start with a capital like all other annotations.
* 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).
4b) The naming conventions also state not to abbreviate to fast, so I 'd
prefer @PropertySpecific over @PropSpecific
[1] Oracle's Java coding conventions, which are the base for JBoss's
coding conventions:
http://www.oracle.com/technetwork/java/codeconv-138413.html
Op 17-01-12 20:20, Mario Fusco schreef:
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]
https://lists.jboss.org/mailman/listinfo/rules-dev
--
With kind regards,
Geoffrey De Smet
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
