[rules-dev] feature request: undo-then

[Mark Proctor]

Geoffrey De Smet wrote:
> How hard would it be to allow something like this in the DRL?
>
> rule "myRule"
>   when
>     t: Total()
>     ... // a bunch of complicated fact constraints
>   then
>     t.increment();
>   undo-then
>     t.decrement();
> end
>
> The current workarounds don't 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.
> - Using logical inserts is a more heavy weight (= slower).
>
This sounds like my logical closure/stateful callback idea that I'd like 
to do, where a closure is called when a rule is no longer true. So in 
the "then" part you would do something using MVEL like lamba expressions:
logicalClosure( [a, b, c] { my closure code here } );

Where a, b, c are the variables to capture from the surrounding scope 
and the my closure here is the code to be executed. In java it would 
look something like

final Map vars = new HashMap();
vars.put( "a", a );
vars.put( "b", b);
vars.put( "c", c);

Closure closure = new Closure() {
   private Map vars;
    public void call() {
        a = vars.get(a");
        b = vars.get("b");
        c = vars.get("c");
        .... my closure code here;
    }
    public void setVars( Map vars ) {
        this.vars = vars;
    }
}

closure.setVars( vars );

so it forms a sort of encapsulated command that is called when the rule 
is no longer true.

Mark

>
>
> Here's another description of this feature request from the user 
> mailing list:
>
>> Ah, well that's my point of ignorance, then.  I was thinking in 
>> stateless mode.  :)   And to do what I suggest in a stateful manner 
>> would require a "modifyLogical" type functionality in place of the 
>> insertLogical.  i.e.
>>
>> modifyLogical (object) {
>>   //do this when the condition obtains
>> } else {
>>   //do this when the condition no longer obtains
>> }
>>
>> Could be an interesting functionality to have, though. 
>
>