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.

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

On 7 April 2011 07:52, Mark Proctor <mproctor(a)codehaus.org <mailto:mproctor@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 <mproctor(a)codehaus.org > <mailto:mproctor@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(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/rules-dev > > > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/rules-dev _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/rules-dev _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

The main point I was trying to make here was that very complex expressions are very, very rare. An acceptable compromise would be to analyse what can be done without busting a vein, and to flag anything anthing else as an error ("expression too complicated") and document the way around, presumably a user-defined variable where the user provides the type. And if the expressions is really so complex, this might even imrove readability ;-)

Wolfgang _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

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