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

[Mario Fusco]

Hi all,

I just added the possibility to enable/disable PropertySpecific as on
option inside the KnowledgeBuilderConfiguration. In particular this new
PropertySpecificOption can have 3 values at the moment:

- DISABLED => the feature is turned off and all the other related
annotations are just ignored
- ALLOWED => this is the default behavior: types are not property specific
unless they are not annotated with @PropertySpecific
- ALWAYS => all types are property specific by default

While using this last option you may want sometimes to make a particular
type not property specific. My first thought to allow that was to add a
boolean argument to the @PropertySpecific annotation so you could write
@PropertySpecific(true) (or just @PropertySpecific since true would be the
default value) when you want to make a type property specific while using
the ALLOWED option (or no option at all) and @PropertySpecific(false) when
you want a type not being property specific while using the option ALWAYS.

As pointed out by Mark this would have the unpleasant side effect that the
default value for @PropertySpecific is actually the unwanted (and useless)
one while using the ALWAYS option. For this reason, instead of adding a
boolean argument to @PropertySpecific, I introduced a second annotation
@NotPropertySpecific having the meaning of @PropertySpecific(false). To be
honest I am not very happy with this last name so I am looking for a better
name for the @PropertySpecific/@NotPropertySpecific pair. Other
possibilities could be: @Watchable/@Unwatchable and @Fine/@Coarse but I
cannot decide between them. Any preference or even better any good
alternative idea?

On a different note, I have a few doubts on how to infer the bit mask of
the watched properties of a type for 2 specific patterns:

1. Person ( this == $child.father )
at the moment while pattern matching on 'this' the Long.MAX_VALUE mask
(meaning watch for changes on ALL the type's properties) is inferred.
Despite this choice is not formally wrong, probably it could be refined a
bit more. In reality I don't think I could do something different if Person
is a JavaBean, but if it is defined as a type declaration in the DRL maybe
I could watch only the properties annotated with @key (if any). Any thought?

2. Person ( )
currently also in this case the inferred mask is Long.MAX_VALUE. I am not
sure this is neither the correct behavior nor the most intuitive one, but
in this case I cannot think to a better strategy. Any suggestion?

Thanks for your feedback,
Mario
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20120207/5f0986f2/attachment.html