[rules-dev] modify (expr) catch 22

Michael Anstis michael.anstis at gmail.com
Fri Apr 8 09:03:44 EDT 2011


I agree with both your and Wolfgangs comments; however it does sound
remarkably like Mark's "Slot Specific" vision.

Perhaps the same issues apply and hence will no doubt be something for Mark
and Edson to sleep on :)

On 8 April 2011 13:57, Geoffrey De Smet <ge0ffrey.spam at gmail.com> wrote:

> > 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
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110408/bdf9453f/attachment.html 


More information about the rules-dev mailing list