[rules-dev] modify( expr ) {....}

[Mark Proctor]

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. 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 <mproctor at codehaus.org 
> <mailto:mproctor at 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 at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110407/69fac079/attachment.html