Yeah, I remember the exchanges from a long time ago about "else" in DRL.
IIRC, Mark wasn't keen on the idea.

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.ne...@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.ans...@gmail.com>wrote:
>
>> I bet Edson can't wait to refactor the parser for that ;)
>>
>>
>> On 31 March 2011 21:11, Mark Proctor <mproc...@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: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 
>>> listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>
>
> --
> Michael D Neale
> home: www.michaelneale.net
> blog: michaelneale.blogspot.com
>
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

Reply via email to