Re: [rules-dev] else

I got the same feeling that Geoffrey had about readability. We added "from" its really easy to get, why not add "else". when Person( name == "darth" ) else [darthIsMissing] A() then .... then.darthIsMissing log("Darth was never found"); end or when Person( name == "darth" ) else { log("Darth was never found"); } A() then .... end "Inline then" could be done with inner rules. Similar to what Mario suggested. rule "Handle Login" when $loginRequest :LoginRequest() AuthorizedUsers( list contains $loginRequest.user ) else [unsuccessfulLoginAttempt] inner rule "Check if Admin" $p :AdminRights( user == $loginRequest.user ) then showAdminMenu(); end then logInUser( $loginRequest.user ); then.unsuccessfulLoginAttempt log( "There was and unsuccessful login attempt with the user name " + $loginRequest.user.name ); end Toni On Aug 19, 2011, at 2:59 PM, Geoffrey De Smet wrote: > 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 <http://then.af/> >> DO.af >> then.at <http://then.at/> >> DO.at <http://DO.at> >> end >> >> could be rewritten as it follows: >> >> rule R1 >> when >> B() >> then >> DO >> rule R1A >> when >> A() >> then >> DO.at <http://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 <http://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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev > > -- > With kind regards, > Geoffrey De Smet > _______________________________________________ > 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 https://lists.jboss.org/mailman/listinfo/rules-dev