<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
On 16/01/2012 13:46, Swindells, Thomas wrote:
<blockquote
cite="mid:DAC86F5F3B84F14088F0DB16092558CA1411BD5FFB@UKMA1.UK.NDS.COM"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family:
"Calibri","sans-serif"; color: rgb(31,
73, 125);">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>
</div>
</blockquote>
I think I replied to a later email on that. We will allow you to
annotate a method with the list of names that refer to the fields it
impacts, but it will only work on direct methods, not nested ones.<br>
<br>
class Person<br>
String firstName<br>
String lastName<br>
<br>
@LinkedProperty("firstName", "lastName") // annotation name
still to be decided<br>
public void setName() {<br>
....<br>
<br>
rule x when<br>
Person( name == "mark proctor" ) // will create a mask for name,
firstName and lastName<br>
<br>
Mark <br>
<blockquote
cite="mid:DAC86F5F3B84F14088F0DB16092558CA1411BD5FFB@UKMA1.UK.NDS.COM"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thomas<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></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 class="moz-txt-link-abbreviated" href="mailto:rules-dev-bounces@lists.jboss.org">rules-dev-bounces@lists.jboss.org</a>
[<a class="moz-txt-link-freetext" href="mailto:rules-dev-bounces@lists.jboss.org">mailto: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)<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">You really should follow naming
conventions Java programmers are familiar<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">with.
javax.xml.bind.annotation.XmlAccessType, for instance,
uses the<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">term "member" for referring to "public
getter/setter pairs", and this comes<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">close to what Drools does.
Alternatively, there's "field" and "property",<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">and I wouldn't worry about the extra
lip mileage - you can always abbreviate<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">to "prop-specific".<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Is this new feature in some way
configurable for the KnowledgeBase?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">There are fact types where modifying
one member results in the change<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">of more than one member. Consider the
very plausible case:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> $f: Fact(...)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> then<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> modify( $f ){ getList().add( $x )
}<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> end<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> when<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> Fact( size > 10 ) # size
implemented as getList().size()<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> then<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Wolfgang<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">PS: The new feature is actually <i>restricting
the sensitivity of the system.</i><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Therefore, I feel that "high-fidelity"
is actually counter-intuitive!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 13 January 2012 23:30, Mark
Proctor <<a moz-do-not-send="true"
href="mailto:mproctor@codehaus.org">mproctor@codehaus.org</a>>
wrote:<o:p></o:p></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">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><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></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 class="moz-txt-link-abbreviated" href="mailto:postmaster@nds.com">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>
<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>