Thanks to everybody for the very useful and constructive feedback. I'll reply to all the points opened in your emails in no particular order:

1. I changed @PropSpecific in @PropertySpecific (with a lower case p in the type declarations for the reason already explained by Mark)

2. At the moment there is no way to enable this feature as a PackageBuilder option. Personally I am not convinced that this will be a good idea, but, if we'll decide to allow it, I suppose it won't be a big effort. Let me know what you think about it.

3. I changed the @Modifies annotation to have a String[] as value so, for instance you'll have to write @Modifies( { "name" } ) and @Modifies( { "firstName", "lastName" } )

4. I didn't implement transitivity in @Modifies. I honestly didn't think about it, but I believe it is something that needs to be done, so I agreed with Mark I will implement this feature (taking care of circular references) after the beta2 will be out.

5. Usage of @Modifies is not allowed on fields at the moment. I am not sure it could be really useful though. The most common scenario where I can think that the @Modifies will be used is for methods that are not related with a class field (the Person.setName() in my former example or even more commonly a clear() method), but if you think that there can be use cases where it can be useful also let me know.

6. The duplicated usage of the same property in @watch (like in the Wolfgang's example @watch( firstName, ! firstName ) ) will end up in a compilation error.

7. En empty @watch() will have no effect and so the listened properties will be only the ones inferred in the pattern.

8. At the moment the usage of @watch on a type not annotated as @PropertySpecific will raise a compilation error. The same doesn't apply if you use @Modifies on a method of a class not annotated with @PropertySpecific, but I took this decision only for performance reasons: if a class is not PropertySpecific I can avoid to read the annotations on all its methods at all. Anyway if you think this last check should be done just let me know: even in this case should be a quite trivial modification.

9. To ask if a rule with a LHS like:

when
    Person( $name: name == "Smith") @watch( ! name )

will ever fire, is not the right question. This property specific feature actually blocks (useless and unwanted) evaluations (or better re-evaluations) when the "name" property of the Person in Wolfgang's example is modified, but nothing prevents the rule to fire when a newly Person with name == "Smith" is inserted.

10. It will be possible to flag a JavaBean as PropertySpecific without modifying its source code by adding a type declaration in the DRL like in:

declare Bean
    @propSpecific
end

Thanks again for your help,
Mario