<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 14/01/2012 08:59, Wolfgang Laun wrote:
<blockquote
cite="mid:CANaj1LcH7TQ57U+ROmmNMyROiFaQoxDpeaTJG7QmWY_tY_G+Uw@mail.gmail.com"
type="cite">
<div>You really should follow naming conventions Java programmers
are familiar</div>
<div>with. javax.xml.bind.annotation.XmlAccessType, for instance,
uses the</div>
<div>term "member" for referring to "public getter/setter pairs",
and this comes</div>
<div>close to what Drools does. Alternatively, there's "field" and
"property",</div>
<div>and I wouldn't worry about the extra lip mileage - you can
always abbreviate</div>
<div>to "prop-specific".</div>
</blockquote>
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.<br>
<blockquote
cite="mid:CANaj1LcH7TQ57U+ROmmNMyROiFaQoxDpeaTJG7QmWY_tY_G+Uw@mail.gmail.com"
type="cite">
<div><br>
</div>
<div>Is this new feature in some way configurable for the
KnowledgeBase?</div>
</blockquote>
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.<br>
<br>
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.<br>
<blockquote
cite="mid:CANaj1LcH7TQ57U+ROmmNMyROiFaQoxDpeaTJG7QmWY_tY_G+Uw@mail.gmail.com"
type="cite">
<div>There are fact types where modifying one member results in
the change</div>
<div>of more than one member. Consider the very plausible case:</div>
<div> $f: Fact(...)</div>
<div> then</div>
<div> modify( $f ){ getList().add( $x ) }</div>
<div> end</div>
<div><br>
</div>
<div> when</div>
<div> Fact( size > 10 ) # size implemented as
getList().size()</div>
<div> then</div>
</blockquote>
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.<br>
<br>
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.<br>
<br>
<br>
<blockquote
cite="mid:CANaj1LcH7TQ57U+ROmmNMyROiFaQoxDpeaTJG7QmWY_tY_G+Uw@mail.gmail.com"
type="cite">
<div><br>
</div>
<div>Wolfgang</div>
<div><br>
</div>
<div>PS: The new feature is actually <i>restricting the
sensitivity of the system.</i></div>
<div>Therefore, I feel that "high-fidelity" is actually
counter-intuitive!</div>
</blockquote>
Name is far too verbose, and was a bit of fun, but it is correct.
""high-fidelity equipment has minimal amounts of <a
href="http://en.wikipedia.org/wiki/Noise" title="Noise">noise</a>
and <a href="http://en.wikipedia.org/wiki/Distortion"
title="Distortion">distortion</a> and an accurate <a
href="http://en.wikipedia.org/wiki/Frequency_response"
title="Frequency response">frequency response</a>."" 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.<br>
<blockquote
cite="mid:CANaj1LcH7TQ57U+ROmmNMyROiFaQoxDpeaTJG7QmWY_tY_G+Uw@mail.gmail.com"
type="cite">
<div><br>
<br>
<div class="gmail_quote">On 13 January 2012 23:30, Mark Proctor
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:mproctor@codehaus.org">mproctor@codehaus.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Mario just got a first cut working for fine grained property
change<br>
listeners. Previously when you call update() it will trigger
revaluation<br>
of all Patterns of the matching object type in the knowledeg
base.<br>
<br>
As some have found this can be a problem, forcing you to
split up your<br>
objects into smaller 1 to 1 objects, to avoid unwanted
evaluation of<br>
objects - i.e. recursion or excessive evaluation problems.<br>
<br>
The new approach now means the pattern's will only react to
fields<br>
constrained or bound inside of the pattern. This will help
with<br>
performance and recursion and avoid artificial object
splitting. We<br>
previously discussed this here:<br>
<a moz-do-not-send="true"
href="http://blog.athico.com/2010/07/slot-specific-and-refraction.html"
target="_blank">http://blog.athico.com/2010/07/slot-specific-and-refraction.html</a><br>
You can see the unit test here:<br>
<a moz-do-not-send="true"
href="https://github.com/droolsjbpm/drools/blob/ca55c78429cbc0f14167c604c413cdc3faaf6988/drools-compiler/src/test/java/org/drools/integrationtests/MiscTest.java"
target="_blank">https://github.com/droolsjbpm/drools/blob/ca55c78429cbc0f14167c604c413cdc3faaf6988/drools-compiler/src/test/java/org/drools/integrationtests/MiscTest.java</a><br>
<br>
The implementation is bit mask based, so very efficient.
When the engine<br>
executes a modify statement it uses a bit mask of fields
being changed,<br>
the pattern will only respond if it has an overlapping bit
mask. This<br>
does not work for update(), and is one of the reason why we
promote<br>
modify() as it encapsulates the field changes within the
statement. You<br>
can follow Mario's chain of work on this at his github
activity feed:<br>
<a moz-do-not-send="true"
href="https://github.com/mariofusco.atom" target="_blank">https://github.com/mariofusco.atom</a><br>
<br>
The adventerous amoung you can pick this up from hudson, or
from maven,<br>
and start playing now. My hope is that this will make drools
much easier<br>
to use:<br>
<a moz-do-not-send="true"
href="https://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/drools-distribution/target/"
target="_blank">https://hudson.jboss.org/hudson/job/drools/lastSuccessfulBuild/artifact/drools-distribution/target/</a><br>
<br>
Btw we are after a name. Drools is not a frame based system,
so "slot<br>
specific" doesn't seem appropropriate. Property Specific
seems a bit of<br>
a mouth full. I'm quite liking High Fidelity Change
Listeners :) any<br>
other suggestions?<br>
<br>
slot-specific is the name used by Jess for this feature,<br>
<a moz-do-not-send="true"
href="http://www.jessrules.com/docs/71/constructs.html"
target="_blank">http://www.jessrules.com/docs/71/constructs.html</a>.
It's also the standard<br>
way that Clips COOL works, which is the Clips OO module.
Although that's<br>
partly a side effect of the triple representation of
properties used in<br>
COOL, and the modifications are triple based. I don't know
what<br>
mechanism Jess is using to enable this.<br>
<br>
Mark<br>
_______________________________________________<br>
rules-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/rules-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
rules-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>