<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
On 07/04/2011 06:54, Wolfgang Laun wrote:
<blockquote
cite="mid:BANLkTi=baWZUULRqxBzcFojNZXNJFCs3kQ@mail.gmail.com"
type="cite"><br>
<br>
<div class="gmail_quote">On 7 April 2011 07:52, Mark Proctor <span
dir="ltr"><<a moz-do-not-send="true"
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;">
<div text="#000000" bgcolor="#ffffff"> On 07/04/2011 06:44,
Wolfgang Laun wrote:
<blockquote type="cite">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>
</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>
</div>
</div>
</blockquote>
DB again was just an example, that expressions could be heavy, we
have no control over that. For instance they could pull from the DB
to get some information about which fact it is that have to lookup
in the WM. Either way it would not be desirable to execute the
entire expression for each setter.<br>
<br>
Mark<br>
<blockquote
cite="mid:BANLkTi=baWZUULRqxBzcFojNZXNJFCs3kQ@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>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'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 moz-do-not-send="true"
href="mailto:mproctor@codehaus.org" target="_blank">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 moz-do-not-send="true"
href="mailto:rules-dev@lists.jboss.org"
target="_blank">rules-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
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 moz-do-not-send="true" href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a>
<a moz-do-not-send="true" 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 moz-do-not-send="true"
href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
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>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
rules-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>