Comments inline, Thomas
From: [email protected] [mailto:[email protected]] On Behalf Of Mario Fusco Sent: 18 January 2012 12:37 To: Rules Dev List Subject: 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) [Swindells, Thomas] ☺ Though I still wonder if the name is a bit vague and meaningless if you don’t know about the feature and what it is called – What about naming it Watchable – this links far better with the language syntax it is supporting? 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. [Swindells, Thomas] I’m more concerned that there should be an option to switch it off - among other things this would allow the model to be updated and released without necessarily having to change all the different rules files in a project in one go. 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. [Swindells, Thomas] Person.setName could equally validly be implemented such that Name is the ‘true’ representation that is persisted in the database, and firstName and lastName are (read only) utility properties to simplify rules writing. 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. [Swindells, Thomas] I’m concerned that this could be confusing, you could assume that it means watch nothing, though this does match the other behaviours that watch is additive and only explicitly subtractive so perhaps it just needs to be clearly documented that @watch adds additional watches and doesn’t 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. [Swindells, Thomas] I’m happy with this, Modifies actually provides a nice piece of metadata about a method even if drools weren’t being used! 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. [Swindells, Thomas] I think it is a question lots of people will ask and wonder, the behavior is actually quite useful and makes sense now you have explained it -we just need to make sure that there is a clear example and explanation in the documentation describing this 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 [Swindells, Thomas] Excellent ☺ One additional question (I was going to say final but then I’d probably be lying) how does this feature interact with type hierarchies? If a parent class is annotated @PropertySpecific then presumably this must be inherited down by the children. What is the behavior of: Parent() @watch(*)? Does this react to all property changes of Child or only the properties declared in Parent? Thomas Thanks again for your help, Mario ________________________________ ************************************************************************************** This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the [email protected] and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary. NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00 **************************************************************************************
_______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
