On 14/01/2012 08:59, Wolfgang Laun wrote:
You really should follow naming conventions Java programmers are familiar
with. javax.xml.bind.annotation.XmlAccessType, for instance, uses the
term "member" for referring to "public getter/setter pairs", and this
comes
close to what Drools does. Alternatively, there's "field" and "property",
and I wouldn't worry about the extra lip mileage - you can always
abbreviate
to "prop-specific".
Edson has gone off dash, due to difficulties in the parser where it'll
be treated as an arithmatic expression unless it's made a hard keyword.
Personally I like dash as it's more readable. We will likely go with
property specific, either prop-specific of propSpecific.
Is this new feature in some way configurable for the KnowledgeBase?
Not at the moment, but it will be for beta2 next week. If we were
starting again, we'd probably have it on by default. But as it changes
the engine behaviour it has to be configured off. You'll annotate the
type declaration to turn it on, per class.
As per the blog article, we also still want to add the @change
annotation to allow additional fine tuning of what the pattern does or
does not listen too.
There are fact types where modifying one member results in the change
of more than one member. Consider the very plausible case:
$f: Fact(...)
then
modify( $f ){ getList().add( $x ) }
end
when
Fact( size > 10 ) # size implemented as getList().size()
then
For any nested accessor use, it'll notify the engine of hte top level
field, i..e. address.city.name will result in an notification of
"address" on the parent object. In the above example the property "list"
will be notified.
For fake setters, that end up setting multiple fields, we'll allow
annotations - still need an annotation name. i.e. setName() would
actually update firstName and lastName, so we'll need an annotation on
name that references those two fields to build the mask.
Wolfgang
PS: The new feature is actually /restricting the sensitivity of the
system./
Therefore, I feel that "high-fidelity" is actually counter-intuitive!
Name is far too verbose, and was a bit of fun, but it is correct.
""high-fidelity equipment has minimal amounts of noise
<http://en.wikipedia.org/wiki/Noise> and distortion
<http://en.wikipedia.org/wiki/Distortion> and an accurate frequency
response <http://en.wikipedia.org/wiki/Frequency_response>."" Slot
specific is allowing you to remove the noise and distortion, i..e
removing the fields you don't care about, as they are just noise.
On 13 January 2012 23:30, Mark Proctor <[email protected]
<mailto:[email protected]>> wrote:
Mario just got a first cut working for fine grained property change
listeners. Previously when you call update() it will trigger
revaluation
of all Patterns of the matching object type in the knowledeg base.
As some have found this can be a problem, forcing you to split up your
objects into smaller 1 to 1 objects, to avoid unwanted evaluation of
objects - i.e. recursion or excessive evaluation problems.
The new approach now means the pattern's will only react to fields
constrained or bound inside of the pattern. This will help with
performance and recursion and avoid artificial object splitting. We
previously discussed this here:
http://blog.athico.com/2010/07/slot-specific-and-refraction.html
You can see the unit test here:
https://github.com/droolsjbpm/drools/blob/ca55c78429cbc0f14167c604c413cdc3faaf6988/drools-compiler/src/test/java/org/drools/integrationtests/MiscTest.java
The implementation is bit mask based, so very efficient. When the
engine
executes a modify statement it uses a bit mask of fields being
changed,
the pattern will only respond if it has an overlapping bit mask. This
does not work for update(), and is one of the reason why we promote
modify() as it encapsulates the field changes within the
statement. You
can follow Mario's chain of work on this at his github activity feed:
https://github.com/mariofusco.atom
The adventerous amoung you can pick this up from hudson, or from
maven,
and start playing now. My hope is that this will make drools much
easier
to use:
https://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/drools-distribution/target/
Btw we are after a name. Drools is not a frame based system, so "slot
specific" doesn't seem appropropriate. Property Specific seems a
bit of
a mouth full. I'm quite liking High Fidelity Change Listeners :) any
other suggestions?
slot-specific is the name used by Jess for this feature,
http://www.jessrules.com/docs/71/constructs.html. It's also the
standard
way that Clips COOL works, which is the Clips OO module. Although
that's
partly a side effect of the triple representation of properties
used in
COOL, and the modifications are triple based. I don't know what
mechanism Jess is using to enable this.
Mark
_______________________________________________
rules-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
