On Tuesday, May 8, 2012 11:18:42 AM UTC-4, Andrew wrote: > > Cool... Do you use kilns at Akamai, and to what extent? > > Another question: you set up coals and clays and eventually kilns are > fired. When you're setting up the coals and clays in code, you're telling > the system about dependencies. Are these dependencies laid out explicitly > enough to be always unambiguous-in-execution? > > (I'm comparing this to an architecture in the object-oriented world where > we ditched static singletons since static things in Java are initialized at > load time and we had no control over the sequence. In our architecture, we > had explicit metadata lists for depends-upon and provides-interface and > everything was registered with a master collection which would construct a > valid sequence for set-up and tear-down according to those metadata lists. > So the ambiguity was eliminated with the use of those lists. And the issue > of passing around more and more arguments was addressed since now you pass > around the single master collection. And each context could have its own > master collection... etc.) > > What were the other ways of managing complexity that you considered and > why did you decide that kilns would fit your needs better? > > I cannot be very specific on what is happening at my work. But I will say the Kiln *resulted* from my experience here.
The dependency graph is implicit in your clay arrangement. However, I do no static analysis of the graph. If you create a cycle, it will fail at runtime. The stack trace should be adequate to see what went wrong. It was a tradeoff. To make dependency analysis automatic would require the call graph be explicit at compile time. I decided that the ability to pass around coals/clays as first class objects, and to evaluate them or not as needed, was more important. Also, they obey all the normal Clojure rules on namespacing and lexical scope. To detect cycles and such would require global knowledge of all namespaces plus control-flow analysis. That would be a very different kind of library. However, in practice I expect it to work well. Since clays name *conceptual values*, their dependencies should easily map into particular categories. That is, a developer may say, “This is part of the dispatch system, so I cannot count on data from the search result system, as that cannot fire until I have resolved dispatch.” >From what you say, I am guessing your Java system was able to do entirely static analysis of the call graph. -- 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
