<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
"(and, beyond that, whether the setter really <i>changes </i>the
value)."<br>
<br>
That's actually a feature I want to add, just not sure of the syntax
and behaviour. In short it should allow a pattern to match on the
either of the rising or falling edges of a match, i.e. it'll only
propagate when the pattern first matches, further rematches will not
propagate unless it is first unmatched (made false). A falling edge
would only propagate and match when the pattern no longer matches,
i.e. stops being true. There is some difficult with the behaviour on
retraction, as you potentially have a handle an object no longer in
the working memory. Anyway worth thinking on, as it would make a
nice 5.5 feature later this year :)<br>
<br>
Mark<br>
On 16/01/2012 14:51, Wolfgang Laun wrote:
<blockquote
cite="mid:CANaj1LeqS5NaH8y0ExTUpPCCdi2L8S1BRUz1QCiYf6Vj3b4E2A@mail.gmail.com"
type="cite">An absolutely watertight and foolproof system would
know which attributes (or getter methods) change due to which
setter method calls (and, beyond that, whether the setter really <i>changes
</i>the value). This, and only this, would be the summit of
"fidelity".<br>
<br>
Anything else is an approximation, and, depending on the measure
you apply, one procedure may be better than another one. Missing a
change is more difficult to circumvent with legacy techniques than
it is to avoid spurious firings.<br>
<br>
Given that the aforementioned analysis is extremely difficult, it
is obvious that a truly high-fidelity reaction to changes can't be
done without users providing dependency information by means of
annotations or some similar technique<br>
<br>
-W<br>
<br>
<br>
<br>
<div class="gmail_quote">On 16 January 2012 14:46, Swindells,
Thomas <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:TSwindells@nds.com">TSwindells@nds.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The
change is reducing the coarseness of the system and so
making it more sensitive to the scope of the change so
I’d say high fidelity is the correct term.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I
agree with you I’m concerned how this works with
non-pure java beans where some of the setters may
update multiple fields, or there may be none bean
methods like a reset() method – I don’t understand how
these would interact in the system, is there a
mechanism to explicitly invalidate a property or mark
the whole lot as dirty.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Thomas</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<div style="border:none;border-left:solid blue
1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #b5c4df
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
<a moz-do-not-send="true"
href="mailto:rules-dev-bounces@lists.jboss.org"
target="_blank">rules-dev-bounces@lists.jboss.org</a>
[mailto:<a moz-do-not-send="true"
href="mailto:rules-dev-bounces@lists.jboss.org"
target="_blank">rules-dev-bounces@lists.jboss.org</a>]
<b>On Behalf Of </b>Wolfgang Laun<br>
<b>Sent:</b> 14 January 2012 08:59<br>
<b>To:</b> Rules Dev List<br>
<b>Subject:</b> Re: [rules-dev] Fine Grained
Property Change Listeners (Slot Specific)</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">You really should follow naming
conventions Java programmers are familiar</p>
</div>
<div>
<p class="MsoNormal">with.
javax.xml.bind.annotation.XmlAccessType, for
instance, uses the</p>
</div>
<div>
<p class="MsoNormal">term "member" for referring to
"public getter/setter pairs", and this comes</p>
</div>
<div>
<p class="MsoNormal">close to what Drools does.
Alternatively, there's "field" and "property",</p>
</div>
<div>
<p class="MsoNormal">and I wouldn't worry about the
extra lip mileage - you can always abbreviate</p>
</div>
<div>
<p class="MsoNormal">to "prop-specific".</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Is this new feature in some way
configurable for the KnowledgeBase?</p>
</div>
<div>
<p class="MsoNormal">There are fact types where
modifying one member results in the change</p>
</div>
<div>
<p class="MsoNormal">of more than one member. Consider
the very plausible case:</p>
</div>
<div>
<p class="MsoNormal"> $f: Fact(...)</p>
</div>
<div>
<p class="MsoNormal"> then</p>
</div>
<div>
<p class="MsoNormal"> modify( $f
){ getList().add( $x ) }</p>
</div>
<div>
<p class="MsoNormal"> end</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"> when</p>
</div>
<div>
<p class="MsoNormal"> Fact( size > 10 ) # size
implemented as getList().size()</p>
</div>
<div>
<p class="MsoNormal"> then</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Wolfgang</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">PS: The new feature is actually <i>restricting
the sensitivity of the system.</i></p>
</div>
<div>
<p class="MsoNormal">Therefore, I feel that
"high-fidelity" is actually counter-intuitive!</p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> </p>
<div>
<p class="MsoNormal">On 13 January 2012 23:30, Mark
Proctor <<a moz-do-not-send="true"
href="mailto:mproctor@codehaus.org"
target="_blank">mproctor@codehaus.org</a>>
wrote:</p>
<p class="MsoNormal">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"
target="_blank">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></p>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
<br>
<hr>
<font color="Gray" face="Arial" size="1"><br>
**************************************************************************************<br>
This message is confidential and intended only for the
addressee. If you have received this message in error,
please immediately notify the <a moz-do-not-send="true"
href="mailto:postmaster@nds.com" target="_blank">postmaster@nds.com</a>
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.<br>
<br>
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<br>
**************************************************************************************<br>
</font>
</div>
<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>
<br>
</blockquote>
</div>
<br>
<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>