Re: [rules-dev] salience alternative with before/after
This is an excellent idea.
It should be reasonable to assume that "salience" and the use of
before/after are mutually exclusive.
Also, salience (irrespective of the way it is defined) should not be
confused with agenda groups. I tell my students that "focus" is
suitable for rule flow "in the large" and salience can be used for
fine-grained prioritizing (with the caveat that more levels than you
have fingers on your hand are evil).
The question is whether before and after should be rule annotations.
If you create a new package element you could define rule precedence
in one central place, exclusively referring to annotations, e.g.:
fire @reset before @cashflow before @print;
fire @yawn before @stretch before @scratch,
@dinner after @hightea after @lunch after @breakfast;
Here you see it at a glance, and it opens fewer possibilities for
creating loops.
-W
On 14/02/2012, Mark Proctor <mproctor(a)codehaus.org> wrote:
Davide has suggested a good idea.
Now that rules support annotations, and annotations with values. We
should add a before/after keyword to each rule. before/after would then
take a list of annotations. The idea is to use this to generate salience
under the covers.
rule resetBalance before( @cashflow ) when then end
rule debit @cashflow when then end
rule credit @cashflow when then end
rule printBalance after(@cashflow ) when then end.
Salience gives one rule priority over another, thus it's declaring an
implicit relationship between rules. Yet it's a magic number that
doesn't easily show this relation, and as the rulebase grows it can be
very hard to determine those relationships as specified by salience from
reading the rules. before/after allows you to specify declarative the
relationships betwen rules in a more maintainable and readable way, even
if under the covers it's just generating:
rule resetBalance salience 100 when then end
rule debit salience 0 when then end
rule credit salience 0 when then end
rule printBalance saliance -100 when then end.
Yes there are agenda-groups and ruleflow-groups, but they can be a bit
cumbersome compared to the simplicity of using salience. This way we get
the simplicity of using salience, without the downfalls of it being a
magic number.
What do people think? Any ideas on how we can improve this? At build
time it would have to report impossible to resolve relationships and barf.
Mark
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev