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

[Wolfgang Laun]

Nice going, Mario.

Re: Annotation names. I've consulted http://www.synonym.com/antonym

@PropertySpecific, @PropertyGeneral

@PropertySensitive, @PropertyInsensitive

@SelectiveModify, @InclusiveModify

@MaskedModify, @FullModify


Re: Person(this==$foo)
I have a strong argument against making a distinction between a Java
Bean and a DRL-declared type. It may happen that you migrate (for
whatever reason) a DRL type to a Java class - and then what?


Re: Person()
What if some following pattern refers to the matched Person via a
variable bound to Person(), e.g.,
$p: Person()
$c: Car( ownerName == $p.name )

(Just being curious: What about the sign bit - the full 64-bit mask
would be Long.MIN_VALUE?)

Cheers
Wolfgang



On 07/02/2012, Mario Fusco <mario.fusco at gmail.com> wrote:
> 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
>