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.s...@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.alive...@gmail.com > > <mailto:esteban.alive...@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.s...@gmail.com <mailto:ge0ffrey.s...@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@lists.jboss.org <mailto:rules-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/rules-dev > > > > > > > > _______________________________________________ > > rules-dev mailing list > > rules-dev@lists.jboss.org <mailto:rules-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/rules-dev > > > > > > > > _______________________________________________ > > rules-dev mailing list > > rules-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/rules-dev > > -- > With kind regards, > Geoffrey De Smet > > > _______________________________________________ > rules-dev mailing list > rules-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev >
_______________________________________________ rules-dev mailing list rules-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev