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

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