Edson,
On 6 May 2011 01:14, Edson Tirelli <ed.tirelli(a)gmail.com> wrote:
Wolfgang,
These are remaining bugs that must be fixed before final. Goal is to
support free form expressions as long as they return a boolean value (for
traditional constraints), or any value (for positional). Period.
(Well, as it's past 5.2.0M2...)
Given that any expression is valid, will there still be a distinction w.r.t.
efficiency, as there was with traditional constraints as opposed to eval()?
If yes, how can I tell whether a constraint expression is "good" or
"bad"?
One might assume that all legacy forms will be handled as efficiently as
now, but it's possible that not only
field == ($var + 1)
but also
field == $var + 1
is efficient. Or, similarly,
field == $var
and (now) also
$var == field
But certainly not
field - 1 == $var
Or, at least, not until some later version ;-)
I repeat this quote (from 5.2.0 Drools Introduction and General User Guide) and
my question, what does it mean? Where is this "documented"? Is this somehow
related to the efficiency issue?
<quote>
As previously we had to document the restricted limitations of a field
constraint on the LHS compared to expressions used inside of an 'eval' or
used on the RHS.
</quote>
Wolfgang
Edson
2011/5/5 Wolfgang Laun <wolfgang.laun(a)gmail.com>
> In the 5.2.0 Drools Introduction and General User Guide, there's section
> 2.1.3.1, Free Form expressions in Constraints (New Parser). It contains
> several examples:
> #1 Person( age * 2 > $anotherPersonsAge + 2 )
> #2 Person( addresses["home"].streetName.startsWith( "High Park" )
)
> #3 Person( isAdult() )
>
> #1 does not compile: Unable to build constraint as 'age * 2' is invalid :
> [Rule name='exa1']
>
> #2 works - although I'd very much prefer not to be swamped with MVEL
> extensions unless I ask for it.
>
> #3 does not compile: Unable to Analyse Expression isAdult():
> [Error: no such identifier: isAdult]
> [Near : {... isAdult() ....}]
>
> Neither rule name nor line number is provided.
>
> Would it please be possible to have a precise statement what one *can*write as a
constraint?
>
>
> <quote>
> As previously we had to document the restricted limitations of a field
> constraint on the LHS compared to expressions used inside of an 'eval' or
> used on the RHS.
> </quote>
>
> I'm sorry, but I do not understand the meaning of this sentence. What does
> it mean, please?
>
> Cheers
> Wolfgang
>
>