Re: [rules-users] When is eval unavoidable?

I forgot to mention... Drools 4.0.4 (the pre-compiled jars downloaded from the Drools web site) Running on HP ProLiant/RedHat Enterprise 4. -A ------------------------------ *From:* rules-users-bounces(a)lists.jboss.org [mailto: rules-users-bounces(a)lists.jboss.org] *On Behalf Of *Edson Tirelli *Sent:* Thursday, April 24, 2008 3:54 PM *To:* Rules Users List *Subject:* Re: [rules-users] When is eval unavoidable? Allen, Both your examples must work just fine: $b : Y(running == true) // attempting to find all applicants named Bob $p : Person(firstName == "Bob") $ap : Applicant(person == $p) I can't think about a reason for them to not work. If they aren't, can you please provide a self contained test case for us to evaluate? Answering your question, in Drools 4, assuming your facts are beans, there should be almost no reason for you to fall back into an eval. The usage of eval is usually related to the need for calculation inside a constraint or the call of functions. []s Edson 2008/4/24 Bagwell, Allen F <afbagwe(a)sandia.gov&gt;: > I'm learning how to use Drools, but eval presents a problem to me when I > am composing rules. I've read the manual and have a basic understanding of > what it is for (very useful in certain situations!), but is there a better > explanation of when it cannot be avoided? > > For example when writing the LHS portion of a rule, I've run into a > problem where literal restrictions alone are fine for one object but > inadequate for another. Like so: > > $a : X(temp < 100) > > $b : Y(running == true) > > In both cases class X and class Y have standard Java bean set up for these > fields with appropriate getters and setters, and the corresponding inserted > facts see these fields being updated from time to time. But whereas the > first fact causes rule activation when the temp field meets the rule > critiera, the second will never work unless it is re-written as: > > $b : Y() > eval ($b.isRunning() == true) > > > I've encountered a similar problem with in-line evals where Drools will > accept an LHS like this: > > // attempting to find all applicants named Bob > $p : Person(firstName == "Bob") > $ap : Applicant(person == $p) > > but it will never cause activation unless you re-write it like this: > > $p : Person(firstName == "Bob") > $ap : Applicant( eval(person == $p) ) > > despite the fact that the Applicant object's person field once set never > changes. > > So is there a more definitive explanation as to why one is forced to use > eval when you would think that simple literal restrictions would be enough? > I've read in other posts that "eval is evil" and to best avoid it unless > necessary, but this is perplexing me because I haven't yet discovered the > way to think about rule composition that prevents eval use from appearing to > be arbitrary. Mostly it's been write what I think *should* work and if it > does then great, it if doesn't then keep adding evals until it does. For the > record, I'm using the java dialect if that makes a difference. > > Thanks! > > -Allen > > > > > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > -- Edson Tirelli JBoss Drools Core Development Office: +55 11 3529-6000 Mobile: +55 11 9287-5646 JBoss, a division of Red Hat @ www.jboss.com _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users