a. is true, but solvable (we will solve it - but it will still be about navigating an object graph).
b. yes that is true, and this is the more "sensitive" one. Basically if you use deep nested structures, there may be performance impacts no matter what.
So the moral, is flatten when you can. In the rules, if you use field constraints early on, then that means that the facts will be "filtered" so that the eval() etc. has to do less work (as it is looking at less objects).
On 10/27/06, Trevor Pocock <[EMAIL PROTECTED]> wrote:
> You cant yet do anything like:Bar(foo.tuo == "...")
> but you can
>doBar($foo: foo)
>eval($foo.getTuo().equals("..."))
> I think its a seperate problem.
Hmmm I think our problems might be at least related.
If i understand it right, the reasons you cant do something like
Bar(foo.tuo == "...")
is because
a. the extracter mechanism needs to build a path from a Bar to its Foo and then
extract the string from the Foo
b. the rule engine needs to know which rules need to be checked when any object
in a path is modified, i.e. when the Bar changes its foo or when the foo changes
its tuo string
or have i missed something?
T
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
