[rules-dev] [Bug]: 5.5.0: binding makes parser accept non-boolean constraint

[Mark Proctor]

On 18 Feb 2013, at 18:38, Wolfgang Laun <wolfgang.laun at gmail.com> wrote:

> I guess I've always spoken my mind in favour of a clean syntax, even
> if it means a little extra typing. I dislike expressions with internal
> bindings; the traditional binding at the start of an expression is
> sufficient.
I don't like nested bindings, I think it was there before due to backwards compatibility.

If we drop it for DRL6, we need to figure out a migration strategy. One possible way is we allow it in the parser stiff, as a config option (off by default, with warning of deprecated feature).

Also field bindings are hangover from the Lisp days. Maybe we don't need property bindings anymore within patterns. Most use cases can use the pattern binding accessor for property access.
when
   $p : Pattern()
then
    println( $p.name );
end

Field bindings allow bindings to complex expression results, involving nested accessors. We can use the "set" proposal I mentioned, and keep those outside of patterns.
when
   $p : Pattern()
   $age : { $p.age * someGlobalIt }  // $age will bind to the result of the expression
then
    println( $p.name + ":" + $age );
end


Mark
> 
> Cheers
> Wolfgang
> 
> On 18/02/2013, Edson Tirelli <ed.tirelli at gmail.com> wrote:
>>   Wolfgang,
>> 
>>   Thank you for reporting. Mario is fixing it.
>> 
>>   On a related note, for Drools 5, for backward compatibility, we still
>> allowed bindings in the middle of expressions. We were discussing if this
>> should be disallowed from Drools 6 forward? Things like:
>> 
>> Person( $name : name == "Bob" || $alive : isAlive && ($age : age > 40 ) )
>> 
>>   Things get quite complicated and a bit hard to read as expressions get
>> more complex. It also clashes with the ternary operator ?:.
>> 
>>   Any thoughts on retaining support for this kind of syntax or removing
>> it?
>> 
>>   Edson
>> 
>> On Mon, Feb 18, 2013 at 7:45 AM, Wolfgang Laun
>> <wolfgang.laun at gmail.com>wrote:
>> 
>>> Below is a self-contained DRL which should not compile because the sum
>>> isn't a boolean expression. (Note that omitting "$x:" results in the
>>> correct diagnostic "predicate ... must be a boolean".)
>>> 
>>> declare Foo
>>>  a: double
>>>  b: double
>>> end
>>> 
>>> rule what
>>> when
>>>    $c: Foo( $x: a + b )
>>> then
>>>    System.out.println( "foo: " + $c );
>>> end
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>> 
>> 
>> 
>> 
>> --
>>  Edson Tirelli
>>  JBoss Drools Core Development
>>  JBoss by Red Hat @ www.jboss.com
>> 
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev