Re: [rules-dev] A remarkable flop
The solution I adopted is to make SwitchState not a subclass of TrackState
but of ElementState, which means that the field(s) to be inherited from
TrackState have to be duplicated in SwitchState. (Luckily, here it is only
one field.)
Adding a type-identifying field goes against the (my) idea of classes for
identifying categories and using them as an implicit constraint in rules,
making them more readable. That's one of the benefits of having an OO RBS,
isn't it?
Anyway, I just wanted to draw people's attention to this hidden trap;
working around it is no problem once you know it is there.
-W
On 12 December 2010 05:06, Greg Barton <greg_barton(a)yahoo.com> wrote:
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.
rule "Xyz state update"
when
$s: XyzState( $id: id, $type: type ... )
$e: Xyz( id == $id, type == $type )
then
//...update $e, retract $s
end
rule "Xyz state for unknown element"
when
$s: XyzState( $id: id, $type: type )
not Xyz( id == $id, type == $type )
then
//... diagnostic, retract $s
end
That oughter do it, and it avoids salience.
--- On *Sat, 12/11/10, Wolfgang Laun <wolfgang.laun(a)gmail.com>* wrote:
From: Wolfgang Laun <wolfgang.laun(a)gmail.com>
Subject: [rules-dev] A remarkable flop
To: "Rules Dev List" <rules-dev(a)lists.jboss.org>
Date: Saturday, December 11, 2010, 10:23 AM
Given classes Switch and Track, and the "natural" class hierarchy
representing state changes for these two elements:
ElementState
TrackState extends ElementState ("free/occupied")
SwitchState extends TrackState (adds "left/right/moving")
Now we have rules for updating Switch and Track elements, like this one:
rule "Xyz state update"
when
$s: XyzState( $id: id, ... )
$e: Xyz( id == $id )
then
//...update $e, retract $s
end
and, since we want to catch bad ids, also
rule "Xyz state for unknown element"
when
$s: XyzState( $id: id )
not Xyz( id == $id )
then
//... diagnostic, retract $s
end
Best practice, wouldn't you say?
Testing by inserting a few of SwitchState objects works fine:
updated: Switch 5 RIGHT occupied
updated: Switch 2 RIGHT
updated: Switch 1 RIGHT occupied
so everything is allright, wouldn't you say?
Add another SwitchState for Switch "4" to the test, and suddenly:
updated: Switch 4 RIGHT
track state for unknown element 5
updated: Switch 2 RIGHT
updated: Switch 1 RIGHT occupied
What's this?!
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 *occasionally *precedes the activation for the match in
the "update" rule.
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"
*before *permitting any update action.
Remarkable.
Wolfgang
-----Inline Attachment Follows-----
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org <http://mc/compose?to=rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
Attachments:
- attachment.html (text/html — 5.4 KB)