On 07/04/2011 06:54, Wolfgang Laun wrote:
On 7 April 2011 07:52, Mark Proctor <mproc...@codehaus.org
<mailto:mproc...@codehaus.org>> wrote:
On 07/04/2011 06:44, Wolfgang Laun wrote:
Perhaps I'm naive, but I think that it should be able to
"compile" this by
a mere expansion:
modify( getFact( var ) ) { setName("yoda"), setColor("blue") }
becomes
getFact( var ).setName("yoda" );
getFact( var ). setColor("blue" );
update( getFact( var ) );
And just warn agsinst side effects.
getFact( var) was just a simplificiation. It can allow for any
expression of any complexity, it could pull from DB.
DB again was just an example, that expressions could be heavy, we have
no control over that. For instance they could pull from the DB to get
some information about which fact it is that have to lookup in the WM.
Either way it would not be desirable to execute the entire expression
for each setter.
Mark
An existing object which is an existing fact in the WM of this session?
-W
It means for each and every setter we would have to evaluate the
whole expression.
Mark
I've written lots of rules for various mini-apps lately, and I've
never had any
reason to use anything except bound variables in a modify anyway.
As for MVEL: I don't trust a "language" that doesn't provide a
definition
of its syntax. The less it is used in Drools (without the user
asking for it)
the better, Sorry if this hurts any feelings, but this reasoning
is backed
up by CENELEC.
Cheers
Wolfgang
On 7 April 2011 07:14, Mark Proctor <mproc...@codehaus.org
<mailto:mproc...@codehaus.org>> wrote:
I'm at the stage where I cannot make this work in a robust
way when
using the java dialect:
modify( getFact( var ) ) { setName("yoda") }
The problem is we have to infer the type of the expression.
If the
expression is complex using variables in methods, we get method
ambiguity if we don't know all variable types. Once we have the
expression type we rewrite this as:
Person obj = ( Person) getFact(var);
obj.setName( "yoda" );
Edson did this originally by using mvel to analyse the
expression. The
problem is that if the expression uses any local variables,
we don't
know what those are. So we need to analyse the entire
consequence, we
started to do this with MVEL but we have reached one too many
stumbling
blocks - most recent of those is MVEL does not understand
java generics.
I've put in about 3 weeks trying to solve this with mvel, and
now had to
stop. When MVEL adds generics we can hopefully resume this
work again.
For now i'm having to roll back to our current behaviour. The
positive
news is that no one has reported issues with this. I'm
guessing most
people use just the fact instance, not expressions, and if
they use an
expression it's simple. So the brittleness is not showing up.
Anyway the work around for now is to explicitley cast, that
should
resolve the issue, if it comes up for anyone. I'm tempted to
say that
expressions are only officially supported when used with casting.
Atleast until we can do robust type inference:
modify( (Person) getFact( var ) ) { setName("yoda") }
Mark
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org <mailto: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
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
