[rules-dev] modify (expr) catch 22

Geoffrey De Smet ge0ffrey.spam at gmail.com
Fri Apr 8 08:57:12 EDT 2011


> Wouldn't it be great(?) and an optimisation that with "true modify" 
> (i.e. no longer a remove and insert) that we could only re-evaluate 
> rules that contained a pattern on a constraint affected by the update?

I doubt if that is possible, consider this case with a calculated getter:

class Person {
    private int age;

    public int getAgeInHours() {
       return 24 * age;
    }

    // getter and setter for int age

}

and these rules:

rule "MyRule1"
   when
     $p : Person(name = "Yoda")
   then
     modify ($p) {
       setAge(300);
     }
end
rule "MyRule2"
   when
     $p : Person(ageInHours > 2400)
   then
     System.out.println("This guy is older than 2400 hours!");
end

After MyRule1 fires and Yoda's age becomes 300, MyRule2 should fire 
because Yoda's older than 2400 hours.

Next, add eval()'s in the mix for more cases like this.

Op 08-04-11 14:11, Michael Anstis schreef:
> Wouldn't it be great(?) and an optimisation that with "true modify" 
> (i.e. no longer a remove and insert) that we could only re-evaluate 
> rules that contained a pattern on a constraint affected by the update?
>
> So,
>
> rule "MyRule"
>   when
>     $p : Person(name = "Yoda")
>   then
>     modify ($p) {
>       setAge(300);
>     }
> end
>
> would not cause "MyRule" to re-evaluate as there's enough information 
> present to ascertain that the modify does not alter the match.
>
> Tell me Wolfgang, why this is such a bad idea - I just know you'll 
> have a good explanation :)
>
> Cheers,
>
> Mike
>
> On 8 April 2011 13:00, Esteban Aliverti <esteban.aliverti at gmail.com 
> <mailto:esteban.aliverti at gmail.com>> wrote:
>
>     Yes, It creates the exact same infinite loop that this code does:
>
>     rule "MyRule"
>       when
>         $p : Person(name = "Yoda")
>       then
>         $p.setAge(300);
>         update($p);
>     end
>
>     As far as I know, the results are the same. The modify() is a more
>     compact way to do a lot of set() invocations and an update().
>     Maybe there are also some other advantages of using modify(),
>     like optimization for example.
>
>     Best Regards,
>
>     XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>
>     Esteban Aliverti
>     - Developer @ http://www.plugtree.com <http://www.plugtree.com>
>     - Blog @ http://ilesteban.wordpress.com
>
>
>
>     On Fri, Apr 8, 2011 at 8:39 AM, Geoffrey De Smet
>     <ge0ffrey.spam at gmail.com <mailto:ge0ffrey.spam at gmail.com>> wrote:
>
>         Related to the modify expression,
>         I 've always wondered about this code:
>
>         rule "MyRule"
>           when
>             $p : Person(name = "Yoda")
>           then
>             modify ($p) {
>               setAge(300)
>             }
>         end
>
>         Doesn't this create an infinite loop? (In my experience it
>         does or at
>         least it takes a lot longer)
>         Because the modify ($p) schedules any rule using a Person back
>         on the
>         agenda to be re-evaluated,
>         so also that rule, which is evaluated and executed again,
>         modifying $p
>         again, ... hence the infinite loop?
>
>         --
>         With kind regards,
>         Geoffrey De Smet
>
>
>         _______________________________________________
>         rules-dev mailing list
>         rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>     _______________________________________________
>     rules-dev mailing list
>     rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev

-- 
With kind regards,
Geoffrey De Smet




More information about the rules-dev mailing list