On 7 April 2011 07:52, Mark Proctor <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.
>
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> 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
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>
>
> _______________________________________________
> rules-dev mailing
> listrules-dev@lists.jboss.orghttps://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
