Perhaps I'm naive, but I think that it should be able to "compile" this by<br>a mere expansion: <br> modify( getFact( var ) ) { setName("yoda"), setColor("blue") }<br>becomes<br> getFact( var ).setName("yoda" );<br>
getFact( var ). setColor("blue" );<br> update( getFact( var ) );<br>And just warn agsinst side effects.<br><br>I've written lots of rules for various mini-apps lately, and I've never had any<br>reason to use anything except bound variables in a modify anyway.<br>
<br>As for MVEL: I don't trust a "language" that doesn't provide a definition<br>of its syntax. The less it is used in Drools (without the user asking for it)<br>the better, Sorry if this hurts any feelings, but this reasoning is backed<br>
up by CENELEC.<br><br>Cheers<br>Wolfgang<br><br><div class="gmail_quote">On 7 April 2011 07:14, Mark Proctor <span dir="ltr"><<a href="mailto:mproctor@codehaus.org">mproctor@codehaus.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'm at the stage where I cannot make this work in a robust way when<br>
using the java dialect:<br>
modify( getFact( var ) ) { setName("yoda") }<br>
<br>
The problem is we have to infer the type of the expression. If the<br>
expression is complex using variables in methods, we get method<br>
ambiguity if we don't know all variable types. Once we have the<br>
expression type we rewrite this as:<br>
Person obj = ( Person) getFact(var);<br>
obj.setName( "yoda" );<br>
<br>
Edson did this originally by using mvel to analyse the expression. The<br>
problem is that if the expression uses any local variables, we don't<br>
know what those are. So we need to analyse the entire consequence, we<br>
started to do this with MVEL but we have reached one too many stumbling<br>
blocks - most recent of those is MVEL does not understand java generics.<br>
I've put in about 3 weeks trying to solve this with mvel, and now had to<br>
stop. When MVEL adds generics we can hopefully resume this work again.<br>
<br>
For now i'm having to roll back to our current behaviour. The positive<br>
news is that no one has reported issues with this. I'm guessing most<br>
people use just the fact instance, not expressions, and if they use an<br>
expression it's simple. So the brittleness is not showing up.<br>
<br>
Anyway the work around for now is to explicitley cast, that should<br>
resolve the issue, if it comes up for anyone. I'm tempted to say that<br>
expressions are only officially supported when used with casting.<br>
Atleast until we can do robust type inference:<br>
modify( (Person) getFact( var ) ) { setName("yoda") }<br>
<br>
Mark<br>
<br>
_______________________________________________<br>
rules-dev mailing list<br>
<a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
</blockquote></div><br>