<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Greg Barton wrote:
<blockquote cite="mid:250116.65014.qm@web81503.mail.mud.yahoo.com"
type="cite">
<pre wrap="">OK, here's where combining the else and undo would get freaky. :)
</pre>
</blockquote>
Btw did you see my otherwise proposal?<br>
<br>
So we would create otherwise-groups, these would ne named groups, like
activation groups.<br>
Person( location == "london" )<br>
Person ( location == "berlin" )<br>
Person( location == OTHERWISE )<br>
<br>
Assuming the three patterns above where each in three different rules.
What this means is for the given named otherwise-group if a field
marked as OTHERWISE is not matched by any other rules in that group
then it's true. Otherwise has long been a feature in decision tables,
but it's not something I've seen supported in technical rules.<br>
<br>
Something else I want to add, particularly focused on systems
automations is a repeat attribute. We already have a duration
attribute, that delays the firing of a rule, but what about the rule
firing again say 30 seconds later if it's still true. So I'd like to
add a repeat command that takes either a integer duration or a cron
like scheduling statement, which may also be combined with an initial
duration rule.<br>
<br>
I've also got ideas around a "execution-group" these would be groups
who's behaviour would be user defined, probably around some sort of
event system, which would provide more flexability than the current
hard coded group behaviours. These execution-groups in theory could
contain custom conflict resolution strategies and also be able to
emulate our existing execution control modes too.<br>
<br>
So as you can see betwee logical closures, else, otherwise-groups,
repeats and execution-groups there is still a lot more we can do to
improve our expressiveness. It is, imho, a necessary step if we are to
take rule engines further to get mainstream adoption as a generic
pramming tool - because currently other than very narrow use cases
rules engines suck for generic programming compared to other languages,
where with enough flexability they should actually excel. Another key
aspect for this will be the adoption of properly ontology support, so
people start creating models that are appropriate for rule engines and
not bastardising their existing deeply nested pojo models.<br>
<br>
<br>
Mark<br>
<br>
<br>
<blockquote cite="mid:250116.65014.qm@web81503.mail.mud.yahoo.com"
type="cite">
<pre wrap="">
rule
when
1: Foo()
2: Bar()
3: Bas()
then
//Everything
undo-then
//When Everything no longer matches
else 3:
//Foo and Bar, No Bas
undo-else 3:
//When (Foo and Bar, No Bas) no longer matches
else 2:
//Foo, No Bar, Bas unknown
undo-else 2:
//When (Foo, No Bar, Bas unknown) no longer matches
else 1:
//No Foo, Bar and Bas unknown
undo-else 1:
//When (No Foo, Bar and Bas unknown) no longer matches
end
The else clause basically is shorthand that generates another rule, one that's triggerd when the indexed indexed fails. The undo would fit right in there, and should be triggered immediately when the indexed condition fails to fail. :) i.e. say "else 3" fired first, then condition 3 matches, (and 1,2 still match) then "undo-else 3" and "then" would fire in that order.
Maybe that's just too much. :)
--- On Thu, 2/19/09, Geoffrey De Smet <a class="moz-txt-link-rfc2396E" href="mailto:ge0ffrey.spam@gmail.com"><ge0ffrey.spam@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">From: Geoffrey De Smet <a class="moz-txt-link-rfc2396E" href="mailto:ge0ffrey.spam@gmail.com"><ge0ffrey.spam@gmail.com></a>
Subject: Re: [rules-dev] feature request: undo-then
To: <a class="moz-txt-link-abbreviated" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
Date: Thursday, February 19, 2009, 5:42 AM
What would an "else clause" do?
Imagine a rule with matches on 5 different fact sets.
How many times would the else part match?
- none (because it matches at least one)
- a very lot (because it matches on any fact set that
isn't that one of those 5)
The "undo-then" is another concept:
it matches when a rule that matched before (in a previous
fireAllRules), now no longer matches.
"undo-then" probably isn't the best name, so
better suggestions are welcome, but "else"
isn't a good name for it as it's not about "not
matching" but about "no longer matching".
Anyway, I 've been thinking and it wouldn't work
for all use cases in drools-solver:
rule
when
q1 : Queen()
q2 : Queen()
eval(q1.getY() - q2.getY() < 10)
then
a.add(q1.getY() - q2.getY());
undo-then
a.subtract(q1.getY() - q2.getY())
end
The y of a queen changes, so the subtract wouldn't
subtract the exact same number that was added.
Any way we could work around that, or is there no avoiding
insertLogical?
With kind regards,
Geoffrey De Smet
Mark Proctor schreef:
</pre>
<blockquote type="cite">
<pre wrap="">Greg Barton wrote:
</pre>
<blockquote type="cite">
<pre wrap="">--- On Wed, 2/18/09, Geoffrey De Smet
</pre>
</blockquote>
</blockquote>
<pre wrap=""><a class="moz-txt-link-rfc2396E" href="mailto:ge0ffrey.spam@gmail.com"><ge0ffrey.spam@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">The current workarounds [to undo-then] are
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">clunky:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">- Writing an negative (opposite) rule
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">isn't efficient:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">it means declaring the rule twice effectively.
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">Also the
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">negative rule is usually using lots of
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">or's and
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">not's which isn't fast.
</pre>
</blockquote>
<pre wrap="">This would be made easier by...drum roll
</pre>
</blockquote>
</blockquote>
<pre wrap="">please...the else clause! :)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">yes we want OPSJ style else statements, edson has an
</pre>
</blockquote>
<pre wrap="">idea on how to do that, just a matter of time :(
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Now, if there was the else clause plus
</pre>
</blockquote>
</blockquote>
<pre wrap="">undo-then/closures you could probably write an entire
complex ruleset in one rule. Might as well just use perl,
then. :P
</pre>
<blockquote type="cite">
<pre wrap="">heh, that's true you would have potentially
</pre>
</blockquote>
<pre wrap="">encapsulated 4 possible executions in a single rule.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
</pre>
</blockquote>
</blockquote>
<pre wrap="">_______________________________________________
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">rules-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">------------------------------------------------------------------------
</pre>
<blockquote type="cite">
<pre wrap="">_______________________________________________
rules-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
rules-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
rules-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>