I read through the docs on jig and component. Basically, the answer proposed by that workflow is: You have to thread your shared state through all the functions (what I described as "Solution 2"), and if you don't want the difficulty of refactoring to that way of doing things, you better just do it that way from the beginning.
OK, not the answer I was hoping for, but I appreciate the pointer. I found it interesting that at the "component" link, under "Disadvantages of the Component Model", Stuart mostly reiterates the points I've been making here, so I guess the issue is understood, it's just that other people are happy with the idea of writing all code this way from the beginning and don't mind being restricted to libraries that use the same methodology. Of course, Clojure itself doesn't follow this component model. Part of that may be because the component model is too new. But I think part of it is that the component model is not always the right choice. Consider decimal precision. Right now, the main mechanism for controlling precision is `with-precision`. This feels natural because precision doesn't make sense as being part of a single "component" -- its relevance potentially spans your entire code base. Furthermore, it would be absurd to have to thread some precision variable as the first input to every single arithmetic operation. Can you imagine how annoying Clojure would be if it made you do that? `with-precision` has the same limitations as bindings -- if you want to produce, for example, a lazy sequence involving decimal arithmetic, you're going to get burned. Maybe in some projects you can get away with just setting a default precision for the entire project. But if you end up needing to deal with a mixture of sequences generated with different precisions, you're going to have major problems. So we have a dilemma -- it's awkward to thread decimal precision through all operations, and binding isn't good enough. This is exactly the kind of thing I'm talking about. To put it bluntly, binding vars is an imperfect solution but we use it because it's the best tool we have in Clojure. Can we do better? -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
