<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Well, seeing as you're already maintaining two parallel type hierarchies, and it's a mismatch between the two that's causing the problem, you might as well use that in the rules.<br><br><div> rule "Xyz state update" <br> when<br> $s: XyzState( $id: id, $type: type ... )<br> $e: Xyz( id == $id, type == $type )<br> then<br> //...update $e, retract $s<br> end<br><br></div><div> rule "Xyz state for unknown element"<br> when<br> $s: XyzState( $id: id, $type: type )</div><div> not Xyz( id == $id, type == $type )</div><div> then<br> //... diagnostic, retract $s<br> end</div><div><br></div><div>That oughter do
it, and it avoids salience.<br>--- On <b>Sat, 12/11/10, Wolfgang Laun <i><wolfgang.laun@gmail.com></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: Wolfgang Laun <wolfgang.laun@gmail.com><br>Subject: [rules-dev] A remarkable flop<br>To: "Rules Dev List" <rules-dev@lists.jboss.org><br>Date: Saturday, December 11, 2010, 10:23 AM<br><br><div id="yiv413986284"><br>
Given classes Switch and Track, and the "natural" class hierarchy representing state changes for these two elements:<br>
ElementState<br>
TrackState extends ElementState ("free/occupied")<br>
SwitchState extends TrackState (adds "left/right/moving")<br>Now we have rules for updating Switch and Track elements, like this one:<br>
rule "Xyz state update" <br>
when<br>
$s: XyzState( $id: id, ... )<br>
$e: Xyz( id == $id )<br>
then<br>
//...update $e, retract $s<br>
end<br>
and, since we want to catch bad ids, also<br>
rule "Xyz state for unknown element"<br>
when<br>
$s: XyzState( $id: id )<br>
not Xyz( id == $id )<br>
then<br>
//... diagnostic, retract $s<br>
end<br>
<br>
Best practice, wouldn't you say?<br><br>Testing by inserting a few of SwitchState objects works fine:<br> updated: Switch 5 RIGHT occupied<br> updated: Switch 2 RIGHT<br> updated: Switch 1 RIGHT occupied<br> so everything is allright, wouldn't you say? <br>
<br>Add another SwitchState for Switch "4" to the test, and suddenly:<br> updated: Switch 4 RIGHT<br> track state for unknown element 5<br> updated: Switch 2 RIGHT<br> updated: Switch 1 RIGHT occupied<br>What's this?!<br>
<br>After some headscratching I realized that the negative rule for the SwitchState's superclass TrackState produces another activation, since, for any Switch element with an id x there clearly isn't a Track element with id x! This activation <i>occasionally </i>precedes the activation for the match in the "update" rule.<br>
<br>This is annoying. Of course, negative salience for the "not" rules fixes this, but who would have thought that you need it with conditions (seemingly!) describing disjoint situations. And the negative salience is counter-intuitive, since normally you'd perform the check "no such element" <i>before </i>permitting any update action.<br>
<br>Remarkable.<br>Wolfgang<br><br><br><br> <br> <br><br><br>
</div><br>-----Inline Attachment Follows-----<br><br><div class="plainMail">_______________________________________________<br>rules-dev mailing list<br><a ymailto="mailto:rules-dev@lists.jboss.org" href="/mc/compose?to=rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br></div></blockquote></div></td></tr></table><br>