I wasn't showing it as a use case, I was showing it as illustrative of the syntax. I could have just done
On 18 August 2011 19:27, Mark Proctor <mproctor@codehaus.org> wrote:
On 18/08/2011 18:17, Wolfgang Laun wrote:I find the above looks cleaner and easier to read, the more we can reduce the need for 'eval' the better. It is a common enough use case that I feel it is worth support.On 18 August 2011 18:38, Mark Proctor <mproctor@codehaus.org> wrote:
We are looking to tighten up accumulate, using a new keyword to
differentiate. It will use ; for separation, to follow a similar form to
a 'for' loop.
acc( CE*;
<func>*;
<guard>? )
so something like:
acc( $o : Order();
$min : min( $o.value ),
$max : max($o.value);
$min > 100 && $max < 100 )
Given that I can do this today using an eval after the accumulate CE: What's the big gain, as compared to the nuisance of yet another CE, with the need to document (which, traditionally, isn't done so eagerly) and teach and learn and getting it free of bugs?
Well, a condition that's never true isn't a good use case. Even after repairing it, the example does not tell you where the min and max, respectively, are. Apart from determining the exact value of mininimum and maximum (which could easily be added, together with locating the containing Order!)
not Order( value <= 100 )
not Order( value >= 200 )
is more descriptive that the rather procedural "for" hidden in the proposed "acc".
Perhaps there are better use case; this one does not convince me.
-W
Acc is used a lot for CEP use cases and we need a syntax that can compete succinctly with alternative approaches - if we look like a dog dinner, we'll lose out to alternative CEP syntaxes. The separation of the segments using ";" gives a clearer distinction too, and it's 'for' loop like nature should more natural to people new to the engine.
Mark
-W
I have wondered if we could use pipes on our functions, to be able to
pass the results of one function into another - just not sure how that
will work or look yet.
func(...) in func(...)
func(...) | func(...)
Mark
_______________________________________________
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
_______________________________________________
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