5:31 p.m.
On 31/03/2011 22:25, Michael Anstis wrote:
Yeah, I remember the exchanges from a long time ago about
"else" in
DRL. IIRC, Mark wasn't keen on the idea.
I didn't like the way Ilog did
"else", where it only works on an "eval"
node and must be the last CE in a rule.
I do however like the OPSJ way of labelled else, and you can have as
many as you like. I have already done the backend for this, with "named"
consequences, so allow multiple consequences per rule. We just haven't
hooked this up into the parser.
Although I have revised this concept further, with "steroids", and
instead called it "named branch". It is likely we'll dothis instead of
simple 'else'. Branch and Else are also the foundations for
opportunistic BC.
http://community.jboss.org/wiki/DroolsLanguageEnhancements#Branch_Labelle...
Branch (Labelled Else)
If the first branch is true it'll continue to propgate to the next node
which is part of the [then] chain, [then] is implicit for the first
branch. If b1 or b2 are true it'll it will activate the labelled block
branch( Pattern(....),
[b1] Pattern(....),
[b2] Pattern(....) )
If none of the branches match then the [b3] default branch is activated.
branch( Pattern(....),
[b1] Pattern(....),
[b2] Pattern(....),
[b3] default )
We can have branches activated when the pattern is not matched.
branch( [!b1] Pattern(....),
[!b2] Pattern(....),
[!b3] Pattern(....) )
In the case of b2 and b3 if the pattern is not true, it'll do nothing,
if the pattern is false the b2 will or b3 will activate. In the case of
first pattern, if it's false the b1 block will activate, if it's true it
will continue to propagate to the rest of the rule. ** is this
consistent and intuitive?
** Each branch does not need to be a Pattern it can have any drl, be
it an 'else', 'not', 'and'. If you want multiple patterns, make
sure to
use the 'and' CE. We shouldn't allow 'or' CE's as I think that
would get
too messy
** At the moment we don't ensure any xor type behaviour. For instance
we could have it that so only one branch can activate, it'll start at
the top and try each one in turn, exiting after the first one is activated.
Anyway, provided my "reversals" make sense it's almost complete in the
guided dtable; it only uses SimpleFieldConstraints so doesn't have the
complexity of compound constraints :)
On 31 March 2011 22:20, Michael Neale <michael.neale(a)gmail.com
<mailto:michael.neale@gmail.com>> wrote:
Otherwise has been dragging on since 2006. There are many
skeletons in that cave.
I will believe it when I see it !
On Fri, Apr 1, 2011 at 7:25 AM, Michael Anstis
<michael.anstis(a)gmail.com <mailto:michael.anstis@gmail.com>> wrote:
I bet Edson can't wait to refactor the parser for that ;)
On 31 March 2011 21:11, Mark Proctor <mproctor(a)codehaus.org
<mailto:mproctor@codehaus.org>> wrote:
on a related note I do plan to add OTHERWISE support at a
DRL level, just no time to do it right now. Once it's
supported at a DRL level, you won't need to as much work
on figuring out the inverse options etc.
Mark
On 31/03/2011 20 <tel:31%2F03%2F2011%2020>:25, Michael
Anstis wrote:
> Hi,
>
> I'm adding support for "otherwise" to (for the time
> being) the guided decision table in Guvnor.
>
> The idea being if you set a cell to represent "otherwise"
> the generated rule is the opposite of the accumulation of
> the other cells; perhaps best explained with an example:-
>
> Person( name == )
> Mark
> Kris
> Geoffrey
> <otherwise>
>
> This would generate:-
>
> Person(name not in ("Mark", "Kris",
"Geoffrey")
>
> Equals is the simple example, this is my thoughts for the
> other operators we might like to support:-
>
> * != becomes "in (<list of the other cells'
values)"
> * < becomes ">= the maximum value of the other cells'
> values
>
>
> For example:-
>
> Person ( age < )
> 10
> 20
> 30
> <otherwise>
>
> Person ( age >= 30 )
>
> * <= becomes "> the maximum value of the other cells'
> values
> * > becomes "<= the minimum value of the other cells'
> values
> * >= becomes "< the minimum value of the other cells'
> values
> * "in" becomes "not in (<a list of all values
> contained in all the other cells' lists of values>)"
>
> For example:-
>
> Person ( name in )
> Jim, Jack
> Lisa, Jane, Paul
> <otherwise>
>
> Person ( name not in ("Jim", "Jack",
"Lisa", "Jane",
> "Paul" ) )
>
> * I'm not sure there is a simple solution for
> "matches" and "soundslike" but welcome advice,
> although a possibility might be to create a
> compound field constraint:-
>
> Person ( name soundslike )
> Fred
> Phil
>
> not Person ( name soundslike "Fred" || soundslike
"Phil" )
>
>
> Would this be considered the most suitable approach?
>
> Inputs and thoughts welcome.
>
> Thanks,
>
> Mike
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Michael D Neale
home: www.michaelneale.net <http://www.michaelneale.net>
blog: michaelneale.blogspot.com <http://michaelneale.blogspot.com>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev