Hi Elias,
I think this is a really interesting suggestion for the case where you do not
have an “accumulating”
value. Because imagine that you want to accept the “next” element, if the sum
of all the previous
is less than Y. To have a similar syntax with an accumulator, we should add
more methods with
additional arguments, right?
For a first release, we opted for the simplest solution so that we can gather
more information on
how people intend to use the new features. Despite that, I really think that it
is an interesting and
more intuitive syntax so could you open a JIRA so that we move the discussion
there, or if you
want I can open it for you.
Thanks a lot for the suggestion,
Kostas
> On Apr 28, 2017, at 1:09 AM, Elias Levy <fearsome.lucid...@gmail.com> wrote:
>
> It would be useful if there were a cleaner syntax for specifying
> relationships between matched events, as in an SQL join, particularly for
> conditions with a quantifier of one.
>
> At the moment you have to do something like
>
> Pattern.
> .begin[Foo]("first")
> .where( first => first.baz == 1 )
> .followedBy("next")
> .where({ (next, ctx) =>
> val first = ctx.getEventsForPattern("first").next
> first.bar == next.bar && next => next.boo = "x"
> })
>
> which is not very clean. It would friendlier if you could do something like:
>
> Pattern.
> .begin[Foo]("first")
> .where( first => first.baz == 1 )
> .followedBy("next")
> .relatedTo("first", { (first, next) => first.bar == next.bar })
> .where( next => next.boo = "x" )
>
>
>
> On Thu, Apr 27, 2017 at 1:21 AM, Kostas Kloudas <k.klou...@data-artisans.com
> <mailto:k.klou...@data-artisans.com>> wrote:
> Glad that this is not a blocker for you and
> you are right that we should clarify it better in the documentation.
>
