Mario,
Can we use a KnowledgeBaseConfiguration option to enable/disable this
feature as a whole?
Edson
On Wed, Jan 18, 2012 at 7:36 AM, Mario Fusco <mario.fu...@gmail.com> wrote:
> 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
>
> _______________________________________________
> rules-dev mailing list
> rules-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
