<br><br><div class="gmail_quote">On 7 April 2011 07:52, Mark Proctor <span dir="ltr">&lt;<a href="mailto:mproctor@codehaus.org">mproctor@codehaus.org</a>&gt;</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;">


  
    
  
  <div text="#000000" bgcolor="#ffffff">
    On 07/04/2011 06:44, Wolfgang Laun wrote:
    <blockquote type="cite">Perhaps I&#39;m naive, but I think that it should be able
      to &quot;compile&quot; this by<br>
      a mere expansion: <br>
         modify( getFact( var ) ) { setName(&quot;yoda&quot;), setColor(&quot;blue&quot;) }<br>
      becomes<br>
         getFact( var ).setName(&quot;yoda&quot; );<br>
         getFact( var ). setColor(&quot;blue&quot; );<br>
         update( getFact( var ) );<br>
      And just warn agsinst side effects.<br>
    </blockquote>
    getFact( var) was just a simplificiation. It can allow for any
    expression of any complexity, it could pull from DB. </div></blockquote><div><br>An existing object which is an existing fact in the WM of this session?<br>-W<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div text="#000000" bgcolor="#ffffff">It means for
    each and every setter we would have to evaluate the whole
    expression.<br>
    <br>
    Mark<br>
    <blockquote type="cite"><br>
      I&#39;ve written lots of rules for various mini-apps lately, and I&#39;ve
      never had any<br>
      reason to use anything except bound variables in a modify anyway.<br>
      <br>
      As for MVEL: I don&#39;t trust a &quot;language&quot; that doesn&#39;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">&lt;<a href="mailto:mproctor@codehaus.org" target="_blank">mproctor@codehaus.org</a>&gt;</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&#39;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(&quot;yoda&quot;) }<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&#39;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( &quot;yoda&quot; );<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&#39;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&#39;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&#39;m having to roll back to our current behaviour. The
          positive<br>
          news is that no one has reported issues with this. I&#39;m
          guessing most<br>
          people use just the fact instance, not expressions, and if
          they use an<br>
          expression it&#39;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&#39;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(&quot;yoda&quot;) }<br>
          <br>
          Mark<br>
          <br>
          _______________________________________________<br>
          rules-dev mailing list<br>
          <a href="mailto:rules-dev@lists.jboss.org" target="_blank">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>
      <pre><fieldset></fieldset>
_______________________________________________
rules-dev mailing list
<a href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
    </blockquote>
    <br>
  </div>

<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>
<br></blockquote></div><br>