Clojurians Log v2

Curious: have you tried anything to combat this.

I'm currently undergoing investigation into alternatives

I have some suspicions / guesses about when and why it happens (and what went right in places where it doesn't happen), but nothing really formal atm

That's perfect

:) we are still rooting the domain out, we feel stuck between a rock and a hard place. The only ideas we have we have seen lead to this same end place.

my knee jerk response is that an undisciplined mix of random parameters is a sign that the shape of the current design doesn't intuitively match up with the domain, and the map keys are being forced to act as an adaptor between the actual data flow and the one the domain needs

but that's just a hunch, not having seen your code

I think putting everything in a map that get's passed everywhere starts to become similar to mutable state. It actually kind of is mutable state, you're just kind of using the state held by the environment (ie stack frames) instead of being explicit about it (ie using atoms

except you have the guarantee that nothing "mutates" from any call unless you access it from the return value

but in a big picture it does introduce the same sorts of problems

The anti pattern I'm particularly struggling with is the introduction of a big bag of state made up of 90% of your system. Then somewhere along the pipeline that map gets enhanced. And in different parts of the codebase it has different keys but the same name.

oh yeah... I remember that problem from a ball of mud product I worked on a few years back

the system map version avoids @dominicm’s issue where the same function gets different variants of the map based on the code path that led to the call

at least the system map has a single point of generation / truth

good point

That depends how granular you go. Even with 2 entry points (Web server, event handler) taking different dependency sets and calling them "deps" it's very confusing. Especially as various parts add derivations to that map (db snapshots, removing the record wrapper) the actual function that performs behaviour may not be taking something that looks anything like your source of truth. You're left baffled for hours wondering how it's calling mongodb directly like that.

If you expand that to each endpoint in your system (an attempt at avoiding the massive deps map and attempting to make each endpoint easier to follow by minimizing dependencies) you can end up with maps which are passed around with injection into them. Having a map of dependencies is synonymous with recipe for disaster in my mind right now.

I've been considering making a non-assocable map to prevent it happening 😂 I don't want to go that far. I'd rather find a new abstraction.

dynamically bound symbols instead of map keys? lol

We joke, but maybe that's not a terrible idea?

My only hang up is async code

async (go blocks and futures and async/thread) all propagate dynamic bindings

now this would be the binding from their call chain and wouldn't reflect later changes under other call chains...

NIO is way more important in http, which means something like netty, which I don't think does dynamic bindings.

you could pass it a function that is created via binding-conveyor-fn

(ins)user=> (source future)
(defmacro future
  "Takes a body of expressions and yields a future object that will
  invoke the body in another thread, and will cache the result and
  return it on all subsequent calls to deref/@. If the computation has
  not yet finished, calls to deref/@ will block, unless the variant of
  deref with timeout is used. See also - realized?."
  {:added "1.1"}
  [& body] `(future-call (^{:once true} fn* [] ~@body)))
nil
(ins)user=> (source future-call)
(defn future-call 
  "Takes a function of no args and yields a future object that will
  invoke the function in another thread, and will cache the result and
  return it on all subsequent calls to deref/@. If the computation has
  not yet finished, calls to deref/@ will block, unless the variant
  of deref with timeout is used. See also - realized?."
  {:added "1.1"
   :static true}
  [f]
  (let [f (binding-conveyor-fn f)
        fut (.submit clojure.lang.Agent/soloExecutor ^Callable f)]
    (reify 
     clojure.lang.IDeref 
     (deref [_] (deref-future fut))
     clojure.lang.IBlockingDeref
     (deref
      [_ timeout-ms timeout-val]
      (deref-future fut timeout-ms timeout-val))
     clojure.lang.IPending
     (isRealized [_] (.isDone fut))
     java.util.concurrent.Future
      (get [_] (.get fut))
      (get [_ timeout unit] (.get fut timeout unit))
      (isCancelled [_] (.isCancelled fut))
      (isDone [_] (.isDone fut))
      (cancel [_ interrupt?] (.cancel fut interrupt?)))))
nil

Then you have to remember to do that :p