Mark Proctor schrieb:
André Thieme wrote:
Mark Proctor schrieb:
Map( this['c'] == 206 )
That should work, we do support MVEL syntax for maps and arrays - we
just don't suppor method calls, yet.
Hello Mark. I just tested it and it indeed works for me.
Although as I understand it, this will be compiled into an expression
using eval (or it will even be only interpreted).
So, if that is true it can't bring any performance advantage.
yes, no performance benefit. As this form of use is a "return value"
really, it should be possible to index (if we assume that nest objects
do not change). Although it's a fair bit of work to do this, but
interesting work - if anyone wants to help out :)
It would be fantastic if there was the same optimization support for
Maps available as it exists for POJOs. Edson gave a great explanation
on how things slow down for cross products.
I thought about one thing:
Could there could maybe be a new attribute, "immutable true" or
something like that, which would signal that the rule writer promises
the engine that only immutable objects are used?
That way my lib could implicitly always set that attribute.
It could certainly be done, lots of ways to cook this - from annotation
on the pojo, type declarations and possibly some annotation on the rule
or pattern itself. If you want to take a crack at this, you know where
to find us :)
The syntax is nothing I worry about. In Clojure, which is a Lisp, I have
macros and can remove any obstacles in the syntax I like. It is trivial
to develop new domain specific languages for rules. So, my rule syntax
for Clojure will look very lispy, and each user is free to change and
extend it. I will also allow the RHS to be written in Clojure code, no
Java needed.
Btw if you are doing "lispy" stuff:
http://blog.athico.com/2008/02/drools-clips.html
http://blog.athico.com/2008/06/drools-clips-progress.html
Ah yes, very interesting.
In principle it is very similar what I do.
With Clojure there is a full featured Lisp on the JVM.
What I do is adding some functions and macros, easy to use, which will
do all the Drools managing and hide it from the user.
It will be simple to add all kinds of syntaxes as soon I am done.
You can have the Jess syntax. Just write a macro and expand it into
mine. It will result in compiled rules code.
So, in some days (when I have time) the project above will be
finished ;-)
see "Null-Safe Bean Navigation"
http://mvel.codehaus.org/MVEL+2.0+Property+Navigation
Ah of course, I forgot the null. And MVEL already has the check built
in.
I think I will also implicitly add it.
And another interesting thing I noticed:
to both rules I added the line
global String s;
and in the LHS's of both rules I removed the "c" and put s at its place.
Then the first thing I did after creating a session was to
(.setGlobal session "s" "c")
The rule 1 accepted this change. I can use s instead of "c". But there
is still the limitation that I can only insert Maps into the session
which do have the String "c" as key. Otherwise: NPE.
The rule 2 (mvel) however does not accept s as a placeholder. I get:
Exception executing predicate this[s] == 206
[Thrown class org.drools.RuntimeDroolsException]
Any ideas how to get rid of the NPE?
We'll have to look into this, probably a bug.
Edson confirmed that this is an MVEL problem.
In a different thread KDR may have discovered another one.
André