Clojurians Log v2

@jeremy642 @mikerod this might be useful in combination with Mike’s suggestion of using Java objects as facts that you could translate into Clojure objects if desired: http://www.clara-rules.org/docs/java/ Basically Clara has a wrapper that you can use instead of needing to do the interop glue work yourself. In case you weren’t already aware.

Also FYI Clara will use the bean properties on Java objects to allow field use by name in the DSL, that isn’t just for records

i.e. Object A has a “getB” method, you can just refer to “b” in a condition like [A (= b some-value)]

My rules implementation does not use Java types for fact types. So the question was how to handle the interop.

(defrule new-return
  "The service is a new return."
  [:approval-status (= (:value this) :new-return)]
  =>
  (insert! {:type :rule/result
            :id :new-return
            :priority 2}))

(r/insert {:type :approval-status :value :new-return})

Without changing the rules to beans or defining the facts with defrecords. The big ?? was how to allow Java to create maps with the keyword format that matched the rules properly.

Perhaps write a rule that matches on Java maps and translates them, then inserts the result? That way you could just insert the Java map into the session

That rule could then just not do anything if only Clojure maps were in the session

So that's one thought. I could write new rules that's sole job was to convert say a Java map if matches to a clojure map.

I haven't progressed on any implementation yet. Been busy but I have some ideas to play with.

:thumbsup:

Note that Clojure maps also implement Java’s map, so you’d need to guard against an infinite loop there (i.e. require that it a Java Map but not a Clojure map)

Thanks

I noticed that clara-rules is on the tech radar by thoughtworks. https://www.thoughtworks.com/radar/languages-and-frameworks

Saw this one back when it was new on there. Pretty cool though!