I like Mario's proposal because I can actually read it.
Those special chars | < are gibberish to me.
The only reason we're not debating to use a new readable, intuitive
keyword, is because of the back-wards compatibility issues involved.
But using unreadable, unintuitive special char just for that, is
probably not a good idea.
I wonder if we reserve new keywords by prefix them with reserved
special char like "@"?
Then we can introduce as many keywords as we want without breaking
backwards compatibility.
Who's our target users for DRL authors?
A) Supersmart computer science guys
B) Blue collar Java programmers
C) Domain experts (= not programmers)
I 'd classify "{notA} < A()" as (given some time to learn it)
readable for A, but not for B and C.
Op 18-08-11 23:35, Mario Fusco schreef:
Hi Mark,
Since you're gathering 2 cents here and there I decided to add
also mine even if I am pretty sure that I am still missing the
whole picture and anyway at the moment I cannot see all the
consequences of what I am going to propose.
To tell you the truth I find the label syntax not very intuitive
and I was wondering if we could avoid it in some way. In the end
what the 90% of the users are asking for is just something like:
rule R
when
A()
then
do something
else
do something else
end
while we are going to give them something that is not exactly the
same:
rule R
when
{notA} < A()
then
do something
then.notA
do something else
end
In particular I was thinking if we could keep the when ... then
... else syntax that should be familiar to the biggest part of the
users and at the same time obtain a flexibility similar to the one
provided by the labels syntax. Probably we could do it with a kind
of nested rules so, for instance, the rule:
rule R1
when
{af} < A() > {at}
B()
then
DO
then.af
DO.af
then.at
DO.at
end
could be rewritten as it follows:
rule R1
when
B()
then
DO
rule R1A
when
A()
then
DO.at
else
DO.af
end
end
Of course the nested rule couldn't be used by the Drools engine as
it is, but we could implement a kind of "linearization" process at
compile time that translates it more or less as:
rule R1_1
when
A()
B()
then
DO
DO.at
end
rule R1_2
when
not A()
B()
then
DO
DO.af
end
In the same way the "or" example:
rule R1
when
( A() > {a1} or
B() > {b1} or
C() > {c1} )
D()
then
DO
then.a1
DO.a1
then.b1
DO.b1
then.c1
DO.c1
end
could be written as:
rule R1
when
D()
then
DO
rule R1A
when
A()
then
DO.a1
end
rule R1B
when
B()
then
DO.b1
end
rule R1C
when
C()
then
DO.c1
end
end
and then linearized at compile time in a similar way as I wrote
before.
Once again I still haven't evaluated all the implications of my
suggestion neither I know if we can cover with it all the cases
proposed by Mark. I am pretty sure I am missing something
important to be honest, but since we are in a "brainstorming
phase" I thought it could worth to consider it at least.
My 2 cents,
Mario
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
With kind regards,
Geoffrey De Smet