4:26 a.m.
To summarize the discussion of the major part of the cited thread:
* There are situations when it is of interest to learn which of the
several constraints of a rule are true and which block it from firing.
* It is known that manually writing a set cooperating rules can
solve this problem (e.g., Rule Design Pattern "Learning the Reason for
Failure")
* Some automatism supporting the creation of such a set would help
Considering such a support, one wonders which level of complexity in
the primary rule it must be able to handle. The task in itself
procures a limitation, e.g., when one pattern must match so that a
binding is available which is used in a successive pattern. (More
formally: the dependency graph of bindings restricts the investigation
of the truth of LHS sub-terms.) Furthermore, any solution using
reverse-engineering from the internal representation of a LHS isn't
simple, and the API for accessing a compiled rule isn't "stable".
But I think that simple scenarios can be handled by a simple rule
authoring tool. I'll explain this by using an example: a rule
investigating offered cars according to a buyer's wishes:
class Car {
String colour;
int price;
int horsepower;
boolean abs;
}
rule "car"
when
$car: Car( colour == "red", price < 1000, horsepower >= 150, abs ==
true )
then ... end
To permit the individual investigation of constraints, this might be
rewritten as:
rule "car"
when
$car: Car()
then end
rule "car colour == \"red\"" extends "car"
when
Car( this == car, colour == "red" )
then // Gosh, a red one!
end
rule "car price < 1000" extends "car"
when
Car( this == car, price < 1000 )
then // Hey, it's cheap enough!
end
And so on. - For a fully automatic process, a "Collector" fact has to
be maintained for each fact (or Cartesian product of facts) matching
the initial rule (i.e., "car"). Into this Collector, positive results
from the extending rules are injected, so that, ultimately, it can be
examined for full information. Here's a couple of examples of rules
doing just that, with the rule id and failure count as positional
properties:
rule "success"
when
$c: Collector( "car", 0; )
then
System.out.println( "Found the car I want: " + $c.get( "car" ) );
end
rule "almost"
when
$c: Collector( "car", 1; )
then
System.out.println( "Almost the car I want: " + $c.get( "car" )
);
$c.missing();
end
Given the Car( "red", 1200, 160, true ), the second rule fires and produces:
Almost found the car I want: Car [colour=red, price=1200,
horsepower=160, abs=true]
missed: price < 1000 in Car
How to write the original rule is the last point. The actual user
interface could be simpler, but here is a basic fluent API:
public String makeRuleText(){
RuleSet ruleSet = new RuleSet( "com.sample", "car" )
.add(new BasicPattern( "car", Car.class ) )
.add( new Constraint( "colour == \"red\"" ) )
.add( new Constraint( "price < 1000" ) )
.add( new Constraint( "horsepower >= 150") )
.add( new Constraint( "abs == true" ) );
return ruleSet.toString();
}
Cheers
Wolfgang
10:17 p.m.
New subject: How to track constraint truth [was: Non short circuit ANDing]
Nice. Very straight forward too.
To summarize my understanding:
Given an initial "business rule" all that has to be done is to implement a
Fluent Builder tool that generates the business rule re-write as
1. an initial root rule (e.g. "car"), that when fired activates a
"Collector"
2. a set of n extended rules (1 for each L-Value predicate participant in the original
business rule)
3. whenever rule i (of the n extended rules) matches, rule i does Collector booking in
its RHS consequence processing. (accounting for predicate participant i)
4. generate a final set of rules that match on the Collector's account of
success/failure and reports on any specific details of that accounting in these final set
of rules' callback(s) to the Collector implementation (e.g. your RHS invoke of
Collector.missing() to render "price > 1000" as point of failure)
I think I get it, starting to exercise this now.
THANKS WOLFGANG!
P.S. Wolfgang, do you have any comment wrt to using WM Listener(s) and their event
callback processing (in conjunction w/ this pattern) as an effective tactic for helping to
account/audit for when rules fail to fire?
-----Original Message-----
From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On
Behalf Of Wolfgang Laun
Sent: Saturday, February 02, 2013 5:26 AM
To: Rules Users List
Subject: [rules-users] How to track constraint truth [was: Non short circuit ANDing]
To summarize the discussion of the major part of the cited thread:
* There are situations when it is of interest to learn which of the several constraints
of a rule are true and which block it from firing.
* It is known that manually writing a set cooperating rules can solve this problem
(e.g., Rule Design Pattern "Learning the Reason for
Failure")
* Some automatism supporting the creation of such a set would help
Considering such a support, one wonders which level of complexity in the primary rule it
must be able to handle. The task in itself procures a limitation, e.g., when one pattern
must match so that a binding is available which is used in a successive pattern. (More
formally: the dependency graph of bindings restricts the investigation of the truth of LHS
sub-terms.) Furthermore, any solution using reverse-engineering from the internal
representation of a LHS isn't simple, and the API for accessing a compiled rule
isn't "stable".
But I think that simple scenarios can be handled by a simple rule authoring tool. I'll
explain this by using an example: a rule investigating offered cars according to a
buyer's wishes:
class Car {
String colour;
int price;
int horsepower;
boolean abs;
}
rule "car"
when
$car: Car( colour == "red", price < 1000, horsepower >= 150, abs ==
true ) then ... end
To permit the individual investigation of constraints, this might be rewritten as:
rule "car"
when
$car: Car()
then end
rule "car colour == \"red\"" extends "car"
when
Car( this == car, colour == "red" )
then // Gosh, a red one!
end
rule "car price < 1000" extends "car"
when
Car( this == car, price < 1000 )
then // Hey, it's cheap enough!
end
And so on. - For a fully automatic process, a "Collector" fact has to be
maintained for each fact (or Cartesian product of facts) matching the initial rule (i.e.,
"car"). Into this Collector, positive results from the extending rules are
injected, so that, ultimately, it can be examined for full information. Here's a
couple of examples of rules doing just that, with the rule id and failure count as
positional
properties:
rule "success"
when
$c: Collector( "car", 0; )
then
System.out.println( "Found the car I want: " + $c.get( "car" ) );
end
rule "almost"
when
$c: Collector( "car", 1; )
then
System.out.println( "Almost the car I want: " + $c.get( "car" )
);
$c.missing();
end
Given the Car( "red", 1200, 160, true ), the second rule fires and produces:
Almost found the car I want: Car [colour=red, price=1200, horsepower=160, abs=true]
missed: price < 1000 in Car
How to write the original rule is the last point. The actual user interface could be
simpler, but here is a basic fluent API:
public String makeRuleText(){
RuleSet ruleSet = new RuleSet( "com.sample", "car" )
.add(new BasicPattern( "car", Car.class ) )
.add( new Constraint( "colour == \"red\"" ) )
.add( new Constraint( "price < 1000" ) )
.add( new Constraint( "horsepower >= 150") )
.add( new Constraint( "abs == true" ) );
return ruleSet.toString();
}
Cheers
Wolfgang
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
________________________________
NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views
contained herein are not intended to be, and do not constitute, advice within the meaning
of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you
have received this communication in error, please destroy all electronic and paper copies
and notify the sender immediately. Mistransmission is not intended to waive
confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted
under applicable law, to monitor electronic communications. This message is subject to
terms available at the following link: http://www.morganstanley.com/disclaimers If you
cannot access these links, please notify us by reply message and we will send the contents
to you. By messaging with Morgan Stanley you consent to the foregoing.
1:02 a.m.
ad 4) I would not generate the final processing since there are too many
possible variations. One might use it as I've shown, but there might
also be an opportunity to use some sort of accumulate of Collectors of
a kind into a list, and you just don't know what to put into the
consequence.
ad PS) I have one Monitor implements AgendaEventListener with a constructor
Monitor( KnowledgeRuntime kRuntime )
that sets itself as a
global Monitor monitor
so that the extended rules can call the Collector method
addFiring( monitor.getRulename() )
so that an evaluation rule can retrieve the names of the rules that have fired.
-W
On 03/02/2013, Cotton, Ben <Ben.Cotton(a)morganstanley.com> wrote:
Nice. Very straight forward too.
To summarize my understanding:
Given an initial "business rule" all that has to be done is to implement a
Fluent Builder tool that generates the business rule re-write as
1. an initial root rule (e.g. "car"), that when fired activates a
"Collector"
2. a set of n extended rules (1 for each L-Value predicate participant in
the original business rule)
3. whenever rule i (of the n extended rules) matches, rule i does
Collector booking in its RHS consequence processing. (accounting for
predicate participant i)
4. generate a final set of rules that match on the Collector's account of
success/failure and reports on any specific details of that accounting in
these final set of rules' callback(s) to the Collector implementation (e.g.
your RHS invoke of Collector.missing() to render "price > 1000" as point of
failure)
I think I get it, starting to exercise this now.
THANKS WOLFGANG!
P.S. Wolfgang, do you have any comment wrt to using WM Listener(s) and
their event callback processing (in conjunction w/ this pattern) as an
effective tactic for helping to account/audit for when rules fail to fire?
-----Original Message-----
From: rules-users-bounces(a)lists.jboss.org
[mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Wolfgang Laun
Sent: Saturday, February 02, 2013 5:26 AM
To: Rules Users List
Subject: [rules-users] How to track constraint truth [was: Non short circuit
ANDing]
To summarize the discussion of the major part of the cited thread:
* There are situations when it is of interest to learn which of the
several constraints of a rule are true and which block it from firing.
* It is known that manually writing a set cooperating rules can solve
this problem (e.g., Rule Design Pattern "Learning the Reason for
Failure")
* Some automatism supporting the creation of such a set would help
Considering such a support, one wonders which level of complexity in the
primary rule it must be able to handle. The task in itself procures a
limitation, e.g., when one pattern must match so that a binding is available
which is used in a successive pattern. (More
formally: the dependency graph of bindings restricts the investigation of
the truth of LHS sub-terms.) Furthermore, any solution using
reverse-engineering from the internal representation of a LHS isn't simple,
and the API for accessing a compiled rule isn't "stable".
But I think that simple scenarios can be handled by a simple rule authoring
tool. I'll explain this by using an example: a rule investigating offered
cars according to a buyer's wishes:
class Car {
String colour;
int price;
int horsepower;
boolean abs;
}
rule "car"
when
$car: Car( colour == "red", price < 1000, horsepower >= 150, abs ==
true
) then ... end
To permit the individual investigation of constraints, this might be
rewritten as:
rule "car"
when
$car: Car()
then end
rule "car colour == \"red\"" extends "car"
when
Car( this == car, colour == "red" )
then // Gosh, a red one!
end
rule "car price < 1000" extends "car"
when
Car( this == car, price < 1000 )
then // Hey, it's cheap enough!
end
And so on. - For a fully automatic process, a "Collector" fact has to be
maintained for each fact (or Cartesian product of facts) matching the
initial rule (i.e., "car"). Into this Collector, positive results from the
extending rules are injected, so that, ultimately, it can be examined for
full information. Here's a couple of examples of rules doing just that, with
the rule id and failure count as positional
properties:
rule "success"
when
$c: Collector( "car", 0; )
then
System.out.println( "Found the car I want: " + $c.get( "car" ) );
end
rule "almost"
when
$c: Collector( "car", 1; )
then
System.out.println( "Almost the car I want: " + $c.get( "car" )
);
$c.missing();
end
Given the Car( "red", 1200, 160, true ), the second rule fires and
produces:
Almost found the car I want: Car [colour=red, price=1200, horsepower=160,
abs=true]
missed: price < 1000 in Car
How to write the original rule is the last point. The actual user interface
could be simpler, but here is a basic fluent API:
public String makeRuleText(){
RuleSet ruleSet = new RuleSet( "com.sample", "car" )
.add(new BasicPattern( "car", Car.class ) )
.add( new Constraint( "colour == \"red\"" ) )
.add( new Constraint( "price < 1000" ) )
.add( new Constraint( "horsepower >= 150") )
.add( new Constraint( "abs == true" ) );
return ruleSet.toString();
}
Cheers
Wolfgang
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
________________________________
NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions
or views contained herein are not intended to be, and do not constitute,
advice within the meaning of Section 975 of the Dodd-Frank Wall Street
Reform and Consumer Protection Act. If you have received this communication
in error, please destroy all electronic and paper copies and notify the
sender immediately. Mistransmission is not intended to waive confidentiality
or privilege. Morgan Stanley reserves the right, to the extent permitted
under applicable law, to monitor electronic communications. This message is
subject to terms available at the following link:
http://www.morganstanley.com/disclaimers If you cannot access these links,
please notify us by reply message and we will send the contents to you. By
messaging with Morgan Stanley you consent to the foregoing.
8:04 p.m.
Let me add 2 more cents to the discussion :)
I am still convinced that there should be better ways for the engine to
provide argumentation
facilities to the users. It's an open topic, we're working on it (better
TMS, defeasible logic, new RETE
algorithm, strong negation, etc..), but right now we have to live with what
5.x provides... at
least until 6.x becomes a reality...
The usecase here can be divided in two parts:
- evaluate a chain of constraints, tracing which one(s) are satisfied and
which ones are not
- evaluate the overall formula, deciding whether an overall consequence
should be fired or not.
Wolfgang's suggestion, as usual, is correct: the constraints have to be
broken apart. The alpha network
evaluates them in a chain and does not notify the results of the
evaluations. However, the proposed
solution (extending a base rule) has a couple of problems
- it relies heavily on (self) joins
- it only handles the positive cases, e.g. color == "red", so that either a
second rule (color != "red")
has to be written, or later one will have to look for the absence of the
"success" fact derived from that
constraint.
So, I'll follow up on my previous suggestion with this proposal:
rule "car"
when
$car: Car( abs == true )
if ( colour == "red" )
do[red]
else do[notRed] // vs break[notRed]
then[red]
System.out.println( ">>> Car is red " + $car );
then[notRed]
System.out.println( ">>> Car is NOT red " + $car );
then
System.out.println( "The best Car is in " + $car );
end
The pattern Car( abs == true ) is a normal pattern: it's the same as the
"base" rule and would
filter objects (@Stephen) which are not relevant for discussion.
The "if/else" structure follows the chain (no joins), but branches depending
on result of the
constraint. Both branches are linked to both a RHS (with an activation
pushed into the agenda)
AND the following patterns in the rule. This means that, using "do" as
opposed to "break", one can
still have a non-blocking sequence of evaluations with partial side effects,
terminating with the
"main" consequence. Each partial consequence can now be logged and possibly
generate intermediate,
control facts as suggested by Wolfgang.
Let me name them "Fulfillment" and "Violation", following on a
previous
experiment we did a couple of
years ago.
At the moment, these facts have to be managed explicitly, but it would be
great if the engine could
provide more declarative ways to handle these use cases.
I.e., something like the following rule allows a great deal of
customization, but the "default" behaviour -
dos insert Fulfillments, elses insert Violations - should probably be
provided by the engine using some keyword ...
rule "car"
when
$car: Car( abs == true )
if ( colour == "red" )
do[red]
else do[notRed] // vs break[notRed]
Success( $car; )
then[red]
System.out.println( ">>> Car is red " + $car );
insert( new Fulfillment( $car, "red" ); )
then[notRed]
System.out.println( ">>> Car is NOT red " + $car );
insert( new Violation( $car, "red" ); )
then
System.out.println( "The best Car is in " + $car );
end
The logic for creating the "Success" fact which unblocks the final
consequence is another matter...
should we require all Fulfills with no Viols? More Fulfills than Viols? The
interesting thing is that now
the "analysis" rules can be decoupled from the basic rule (again somehting
we'd need to improve
and provide out of the box)
However, notice that this syntax is already PARTIALLY working... and while
it is semantically designed
to be *equivalent* to a chain of extended rules, the internal implementation
is (supposedly) more efficient.
UNFORTUNATELY:
@Mario: I tried to use more than one "if" in a rule:
$car: Car( abs == true )
if ( colour == "red" ) do[red] else do[notRed]
if ( price < 1000 ) do[cheap] else do[notCheap]
but I get a compilation error ... is this a bug or simply the feature has
not been fully implemented yet?
Best
Davide
--
View this message in context:
http://drools.46999.n3.nabble.com/rules-users-How-to-track-constraint-tru...
Sent from the Drools: User forum mailing list archive at Nabble.com.
1:25 a.m.
Hello Davide,
a few comments, see inline.
On 04/02/2013, Davide Sottara <dsotty(a)gmail.com> wrote:
I am still convinced that there should be better ways for the engine to
provide argumentation facilities to the users.
See my final aside.
The usecase here can be divided in two parts:
- evaluate a chain of constraints, tracing which one(s) are satisfied and
which ones are not
- evaluate the overall formula, deciding whether an overall consequence
should be fired or not.
Extension to the second part: There may be more than one overall
consequence, perhaps alternatives, perhaps in parallel or both.
Wolfgang's suggestion, as usual, is correct: the constraints have to be
broken apart. The alpha network
evaluates them in a chain and does not notify the results of the
evaluations. However, the proposed
solution (extending a base rule) has a couple of problems
- it relies heavily on (self) joins
Not necessarily - the secondary conditions could be written using
eval(). Also, pattern binding could be made to recognize a previous
binding. And, re the
argument for better efficiency below, efficiency isn't my foremost
worry when the goal is to provide a sound way of solving a user's
problem.
- it only handles the positive cases, e.g. color == "red",
so that either a
second rule (color != "red")
has to be written, or later one will have to look for the absence of the
"success" fact derived from that
constraint.
But below you introduce Fulfillment and Violation facts and wonder
about the way to clinch the entire procedure. The Collector fact I use
provides all the answers, and it's just a single fact, not one for
each constraint.
So, I'll follow up on my previous suggestion with this proposal:
[snip]
At the moment, these facts have to be managed explicitly, but it
would be
great if the engine could
provide more declarative ways to handle these use cases.
I.e., something like the following rule allows a great deal of
customization, but the "default" behaviour -
dos insert Fulfillments, elses insert Violations - should probably be
provided by the engine using some keyword ...
rule "car"
when
$car: Car( abs == true )
if ( colour == "red" )
do[red]
else do[notRed] // vs break[notRed]
Success( $car; )
then[red]
System.out.println( ">>> Car is red " + $car );
insert( new Fulfillment( $car, "red" ); )
then[notRed]
System.out.println( ">>> Car is NOT red " + $car );
insert( new Violation( $car, "red" ); )
then
System.out.println( "The best Car is in " + $car );
end
Mentally extending this by adding price, HP and ABS, I begin to yearn
for a generator that takes all the plodding work off my hands... Well,
I needed that for churning out the extensions, so I can't claim to be
better here :-)
I say: let users gain experience with a procedure that doesn't require
any built-ins and learn what would be a really helpful extension to
the engine, and *then* decide what to add to the engine.
As an aside: It's commendable to look for more and more additional
features, but remember the fate of the Vasa. ;-)
Cheers
Wolfgang
1:53 a.m.
Hi Wolfgang,
We're more on the same page than it might seem... :)
The new - experimental - syntax was reviewed several times to make sure it
was semantically
equivalent (and thus replaceable) to an appropriate set of rules extending
each other
(see the links I posted previously), which in this case would be exactly the
ones you recommended.
It is just meant to be more compact - possibly facilitating its generation
by builders or templates -
but at the same time it supports a built-in implementation.
It is however more general than this use case, which could use some extra
automation as far as the
management of the evaluations is concerned.
Or, none at all, letting users adopt whatever solution is more appropriate.
You suggested a more general CollectorFact, I used the more granular
Fulfill/Viol...
from a certain perspective they're equivalent, and definitely not the only
option :)
Davide
--
View this message in context:
http://drools.46999.n3.nabble.com/rules-users-How-to-track-constraint-tru...
Sent from the Drools: User forum mailing list archive at Nabble.com.
4:36 a.m.
Anyway, I can experiment nicely with my hack, and this would be a good
starting point for investigating what kind of support users might need.
Given the definition of a rule set:
new RuleSet( "com.sample", "car" )
.add(new BasicPattern( "car", Car.class ) )
.addSplit( "colour == 'red', price < 2000, horsepower >= 150, abs
== true" );
and Car facts
new Car( "HotRod 1", "red", 1200, 160, true );
new Car( "HotRod 2", "red", 1100, 140, true );
new Car( "HotRod 3", "black", 3000, 100, false );
You might add evaluation rules such as the ones below, likely examples
for what users might require:
rule "success, or near miss"
when
$c: Collector( "car"; failureCount <= 1 )
then
System.out.println( "Candidate for the car I want: " + $c.get(
"car" ) );
$c.missing();
end
------------------------------
Candidate for the car I want: Car [id = HotRod 1, colour=red,
price=1200, horsepower=160, abs=true]
Candidate for the car I want: Car [id = HotRod 2, colour=red,
price=1100, horsepower=140, abs=true]
missed: horsepower >= 150 in Car, values: getHorsepower() = 140
-------------------------------
rule "no chance"
when
$c: Collector( "car"; successCount == 0 )
then
System.out.println( "Absolutely not: " + $c.get( "car" ) );
$c.missing();
end
-------------------------------
Absolutely not: Car [id = HotRod 3, colour=black, price=3000,
horsepower=100, abs=false]
missed: colour == 'red' in Car, values: getColour() = black
missed: price < 2000 in Car, values: getPrice() = 3000
missed: horsepower >= 150 in Car, values: getHorsepower() = 100
missed: abs == true in Car, values: isAbs() = false
-------------------------------
rule "collect good offers"
when
accumulate( $c: Collector( "car"; failureCount <= 1 ), $list:
collectList( $c.get("car") ) )
then
System.out.println( "Summary:" );
for( Object object: $list ) System.out.println( (Car)object );
end
-------------------------------
Summary:
Car [id = HotRod 2, colour=red, price=1100, horsepower=140, abs=true]
Car [id = HotRod 1, colour=red, price=1200, horsepower=160, abs=true]
-------------------------------
On 04/02/2013, Davide Sottara <dsotty(a)gmail.com> wrote:
Hi Wolfgang,
We're more on the same page than it might seem... :)
The new - experimental - syntax was reviewed several times to make sure it
was semantically
equivalent (and thus replaceable) to an appropriate set of rules extending
each other
(see the links I posted previously), which in this case would be exactly
the
ones you recommended.
It is just meant to be more compact - possibly facilitating its generation
by builders or templates -
but at the same time it supports a built-in implementation.
It is however more general than this use case, which could use some extra
automation as far as the
management of the evaluations is concerned.
Or, none at all, letting users adopt whatever solution is more appropriate.
You suggested a more general CollectorFact, I used the more granular
Fulfill/Viol...
from a certain perspective they're equivalent, and definitely not the only
option :)
Davide
--
View this message in context:
http://drools.46999.n3.nabble.com/rules-users-How-to-track-constraint-tru...
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
7:32 a.m.
While I am following this discussion with great interest, I am also feeling a
little anxious about what I see here. In the parent thread, I recall that
there was some talk of this functionality being contained in some kind of
adjunct, or "outside the rule engine", application. I get the impression
that what is now being discussed are changes to the rule-language that would
allow this functionality to exist within the primary rule-engine. If I am
mistaken (which I hope I am), please let me know.
My concern about this stems from the fact that I have spent the better part
of two years telling Java developers that this wasn't merely a different
language for them to learn, but is more of a shift in the way that they
think. The direction this discussion seems to be going (again, I hope I am
misreading it), is to back away from the declarative programming approach.
--
View this message in context:
http://drools.46999.n3.nabble.com/rules-users-How-to-track-constraint-tru...
Sent from the Drools: User forum mailing list archive at Nabble.com.
8:23 a.m.
I can understand the "feeling anxious" bit but I think that you foster this
feeling with a bad reason. What Davide and I posted are both declarations
of a more complex fact evaluation - in my case it is necessarily written
as if the API would provide such a rule declaration.
Don't be confused by the introduction of "if" in the
"experimental"
(Davide) syntax. This isn't any more non-declarative than the eval()
of old.
-W
On 04/02/2013, Lance <lance.leverich(a)gmail.com> wrote:
While I am following this discussion with great interest, I am also
feeling
a
little anxious about what I see here. In the parent thread, I recall that
there was some talk of this functionality being contained in some kind of
adjunct, or "outside the rule engine", application. I get the impression
that what is now being discussed are changes to the rule-language that
would
allow this functionality to exist within the primary rule-engine. If I am
mistaken (which I hope I am), please let me know.
My concern about this stems from the fact that I have spent the better part
of two years telling Java developers that this wasn't merely a different
language for them to learn, but is more of a shift in the way that they
think. The direction this discussion seems to be going (again, I hope I am
misreading it), is to back away from the declarative programming approach.
--
View this message in context:
http://drools.46999.n3.nabble.com/rules-users-How-to-track-constraint-tru...
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
9:47 a.m.
Thanks for the gentle reply. My initial reply was made without having read
your latest example. The "experimental" syntax was what had me getting
anxious, as I already have to fend off the Java developers that want to
"just write the rules in Java" (i.e. they don't want to have to think in a
non-procedural manner).
As for the eval() of old, I thought that it was a discouraged practice to
use it; precisely because it was considered to be non-normative in its
approach. Again, it may have just been my interpretation of the
documentation that was out-of-line with the mainstream thinking here.
--
View this message in context:
http://drools.46999.n3.nabble.com/rules-users-How-to-track-constraint-tru...
Sent from the Drools: User forum mailing list archive at Nabble.com.
10:21 a.m.
On 04/02/2013, Lance <lance.leverich(a)gmail.com> wrote:
Thanks for the gentle reply. My initial reply was made without having
read
your latest example. The "experimental" syntax was what had me getting
anxious, as I already have to fend off the Java developers that want to
"just write the rules in Java" (i.e. they don't want to have to think in a
non-procedural manner).
Keep it up :)
As for the eval() of old, I thought that it was a discouraged practice to
use it; precisely because it was considered to be non-normative in its
approach. Again, it may have just been my interpretation of the
documentation that was out-of-line with the mainstream thinking here.
Up to Drools 5.1.x the constraint syntax was rather restricted, so the
eval() was the last resort, to be used in case the native DRL wouldn't
let you. Meanwhile, distinctions have disappeared, so that "any"
boolean expression should be possible as a constraint, not needing the
eval wrapper.
eval() was (also) discouraged because it wouldn't let the engine use
more efficient fact evaluations by indexing.
-W
--
View this message in context:
http://drools.46999.n3.nabble.com/rules-users-How-to-track-constraint-tru...
Sent from the Drools: User forum mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
4310
days inactive
4312
days old
10 comments
4 participants
participants (4)
-
Cotton, Ben -
Davide Sottara -
Lance -
Wolfgang Laun