you can put it all in eval: an eval is really just a wrapper around
arbitrary code, not unlike the old <condition> sections in 2.x.
There IS a limitation where an eval() can't span lines, but we are working
to resolve this (in theory there is no reason why it can be arbitrarily
big).
yes, you can put the eval anywhere, as long as it is after any bound
variables that are being used in the eval:
(and an eval can follow a column declaration on the same line - lines are
not important other then when you are using a DSL - in terms of the DSL
being applied one line at a time).
Yes, there is an overall "And" over all the top level conditions that are
not part of an explicity and/or.
Hope that helps !
Michael.
On 4/2/06, Yuesong Wang <[EMAIL PROTECTED]> wrote:
>
> Michael,
>
> You are right, eval is more appropriate, but I can't
> quite do what I want with eval yet, which is something
> like this:
>
> o : MyObject (name == "something")
> eval(o.getProp("prop1") == "val1"))
> eval(o.getProp("prop2") == "val2"))
>
> 2.5 already provides the equivelant of above. I'm
> really using the predicate syntax now as a workaround
> so that I can have multiple conditions each on its own
> line.
>
> Why not just put all expressions in one eval? I
> haven't got to the details of DSL, but from what I
> have gathered so far, having eval expressions on
> separate lines seem to allow more flexible DRL-DSL
> mapping. Because we can mix and match the atomic
> expressions differently in different rules. For
> example, in one rule, we may have
>
> prop1 of MyObject is value1
> prop2 of MyObject is value2
> prop3 of MyObject is value3
>
> in the other, we may only need
>
> prop1 of MyObject is value1
> prop2 of MyObject is value2
>
> These will be mapped to separate eval lines using the
> sample DSL statement. If we cannot do multiple evals,
> we can't really do that. We will have to instead
> create two bigger, un-reusable DSL statements.
>
> Furthermore, does eval have to come at the end of all
> conditions? I.e. will we be able to do this?
>
> o : MyObject( name == "something" )
> eval (o.getProp("prop1") == "val1")
> MyObject( value == "some value" )
>
> When it is all AND relationship among the conditions,
> it doesn't really matter, but being able to put the
> conditions in any order allows logical groupings of
> the conditions, which could make the rule a bit easier
> to read.
>
> Thanks for taking the time to answer my questions when
> you are busy trying to get the release out. Great job
> with 3.0!
>
> Yuesong
>
> --- Michael Neale <[EMAIL PROTECTED]> wrote:
>
> > o : MyObject (name == "something")
> > eval(o.getProp("prop") == "val"))
> >
> > I think will do what you want.
> >
> > On 4/1/06, Yuesong Wang <[EMAIL PROTECTED]>
> > wrote:
> > >
> > > Hi,
> > >
> > > I'm doing something like this:
> > >
> > > o : MyObject (name == "something")
> > > MyObject (n : name -> (o.getProp("prop") ==
> > "val"))
> > >
> > > As you can see in the second condition, in order
> > to
> > > use the predicate constraint, I have to bound an
> > > unrelated column. Is there a way to use the
> > predicate
> > > constraint without the column binding?
> > >
> > > I know I can use eval, but put everything that is
> > not
> > > a column in eval can get it really cluttered in a
> > > hurry.
> > >
> > > So I think it will be helper to be able to filter
> > the
> > > facts based on a non-column, such as:
> > >
> > > o : MyObejct (name == "something")
> > > MyObject( -> (o.getProp("prop") == "val")
> > >
> > > better yet, without the "->", but I understand if
> > > there has to be something to indicate that it is a
> > > predicate constraint.
> > >
> > >
> > > Thanks,
> > >
> > > Yuesong
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Tired of spam? Yahoo! Mail has the best spam
> > protection around
> > > http://mail.yahoo.com
> > >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
