<div><br></div> Mario,<div><br></div><div> Can we use a KnowledgeBaseConfiguration option to enable/disable this feature as a whole?</div><div><br></div><div> Edson<br><br><div class="gmail_quote">On Wed, Jan 18, 2012 at 7:36 AM, Mario Fusco <span dir="ltr"><<a href="mailto:mario.fusco@gmail.com">mario.fusco@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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:<br>
<br>1. I changed @PropSpecific in @PropertySpecific (with a lower case p in the type declarations for the reason already explained by Mark)<br>
<br>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.<br>
<br>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" } )<br><br>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.<br>
<br>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.<br>
<br>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.<br><br>7. En empty @watch() will have no effect and so the listened properties will be only the ones inferred in the pattern.<br>
<br>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.<br>
<br>9. To ask if a rule with a LHS like:<div class="im"><br><br> when<br> Person( $name: name == "Smith") @watch( ! name )<br><br></div>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.<br>
<br>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:<br><br>declare Bean<br> @propSpecific<br>end <br><br>Thanks again for your help,<br>
Mario<br>
<br>_______________________________________________<br>
rules-dev mailing list<br>
<a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br> Edson Tirelli<br> JBoss Drools Core Development<br> JBoss by Red Hat @ <a href="http://www.jboss.com">www.jboss.com</a><br>
</div>