Greg Barton schrieb:
There's no reason why a rete based system couldn't use maps
as first
class objects, but Drools is heavily oriented towards POJOS. Using
eval in the way you have is pretty much the way to go.
Thanks for confirming that.
For now I know that I am doing it right by using eval and that this
means that rules for typical Clojure objects will not benefit from some
of the optimizations Drools usually can apply.
Maybe it will change in the future.
As long as type information is accessible (both for first class
types
and their members) you should be able to have the left hand side of a
rule (the conditions) be as it is now.
I think that if Maps become 1st class objects there could be a different
Syntax, without using eval.
If you lobby the devs hard enough and get others on your side you
may
be able to convince them to go in that direction, but I doubt it
would be possible before version 6 or so, if that early. (And I'm
not even sure it's possible.)
At this point it is mostly interesting for me to get Drools working with
Clojure together and concentrate on correctness. The goal is that users
of my lib can use do all typical things people do with Drools without
writing Java code. Everything, including the rules, would be written in
Clojure.
But of course it would be very interesting if the devs could indeed have
Clojure in mind. I don't know how reusable the existing code is, for
using Maps without the need for eval and with having the respective
performance advantages.
I understand that the looup of the value for a given key can not be
optimized away. On my hardware get() is limited to "only" 1000 calls
per msec and core. Reading a field from a POJO is faster.
If I understand it correctly then the "problem" with eval is that it
needs to be executed each time, and no clever caching can be done.
So, eliminating that by having Maps being 1st class is what sounds
interesting.
When I refer to Maps and Clojure, then I talk about Maps having only
very few key/value pairs, just like POJOs, and being immutable.
This immutability may even be very helpful for optimization. It is
guaranteed that a given object will never change.
I hope the devs will find it okay if I make some concrete suggestions
in the coming weeks.
Sunny greetings,
André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/