Re: [rules-dev] feature request: undo-then
OK, here's where combining the else and undo would get freaky. :)
rule
when
1: Foo()
2: Bar()
3: Bas()
then
//Everything
undo-then
//When Everything no longer matches
else 3:
//Foo and Bar, No Bas
undo-else 3:
//When (Foo and Bar, No Bas) no longer matches
else 2:
//Foo, No Bar, Bas unknown
undo-else 2:
//When (Foo, No Bar, Bas unknown) no longer matches
else 1:
//No Foo, Bar and Bas unknown
undo-else 1:
//When (No Foo, Bar and Bas unknown) no longer matches
end
The else clause basically is shorthand that generates another rule, one that's
triggerd when the indexed indexed fails. The undo would fit right in there, and should be
triggered immediately when the indexed condition fails to fail. :) i.e. say "else
3" fired first, then condition 3 matches, (and 1,2 still match) then "undo-else
3" and "then" would fire in that order.
Maybe that's just too much. :)
--- On Thu, 2/19/09, Geoffrey De Smet <ge0ffrey.spam(a)gmail.com> wrote:
From: Geoffrey De Smet <ge0ffrey.spam(a)gmail.com>
Subject: Re: [rules-dev] feature request: undo-then
To: rules-dev(a)lists.jboss.org
Date: Thursday, February 19, 2009, 5:42 AM
What would an "else clause" do?
Imagine a rule with matches on 5 different fact sets.
How many times would the else part match?
- none (because it matches at least one)
- a very lot (because it matches on any fact set that
isn't that one of those 5)
The "undo-then" is another concept:
it matches when a rule that matched before (in a previous
fireAllRules), now no longer matches.
"undo-then" probably isn't the best name, so
better suggestions are welcome, but "else"
isn't a good name for it as it's not about "not
matching" but about "no longer matching".
Anyway, I 've been thinking and it wouldn't work
for all use cases in drools-solver:
rule
when
q1 : Queen()
q2 : Queen()
eval(q1.getY() - q2.getY() < 10)
then
a.add(q1.getY() - q2.getY());
undo-then
a.subtract(q1.getY() - q2.getY())
end
The y of a queen changes, so the subtract wouldn't
subtract the exact same number that was added.
Any way we could work around that, or is there no avoiding
insertLogical?
With kind regards,
Geoffrey De Smet
Mark Proctor schreef:
> Greg Barton wrote:
>> --- On Wed, 2/18/09, Geoffrey De Smet
<ge0ffrey.spam(a)gmail.com> wrote:
>>
>>
>>> The current workarounds [to undo-then] are
clunky:
>>> - Writing an negative (opposite) rule
isn't efficient:
>>> it means declaring the rule twice effectively.
Also the
>>> negative rule is usually using lots of
or's and
>>> not's which isn't fast.
>>>
>>
>> This would be made easier by...drum roll
please...the else clause! :)
>>
> yes we want OPSJ style else statements, edson has an
idea on how to do that, just a matter of time :(
>> Now, if there was the else clause plus
undo-then/closures you could probably write an entire
complex ruleset in one rule. Might as well just use perl,
then. :P
> heh, that's true you would have potentially
encapsulated 4 possible executions in a single rule.
>>
>>
_______________________________________________
>> rules-dev mailing list
>> rules-dev(a)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
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev