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

[Swindells, Thomas]

I'd vote for something based upon the *Modfy choices - I think they are far clearer that they have something to do with drools than the PropertySpecific which could easily belong to Spring, JPA, BeanXYZ or a whole host of other technologies!

Thomas

> -----Original Message-----
> From: rules-dev-bounces at lists.jboss.org [mailto:rules-dev-
> bounces at lists.jboss.org] On Behalf Of Wolfgang Laun
> Sent: 07 February 2012 10:57
> To: Rules Dev List
> Subject: Re: [rules-dev] Fine Grained Property Change Listeners (Slot Specific)
>
> 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
> >
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev


**************************************************************************************
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster at nds.com 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
**************************************************************************************