Mark,
Probably I over simplification thing, but It's not possible to translate it to:
Object fact = getFact(var)
Method method = fact.getClass().getMethod("setName", new Class[]
{param1.getClass(), .., paramN.getClass()});
method.invoke(fatc, parm1, .., paramN);
-- Bauna
On 04/07/2011 02:14 AM, Mark Proctor 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev