Announcement Announcement Module
No announcement yet.
clojure & spring? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • clojure & spring?

    related to this post -[email protected]/msg14185.html
    Is spring(the dependency injection concept) tied only to Object Oriented Programming style?
    Or cant it be also applied to arbitary code fragments?

    -Hari Sujathan
    (somehow not able to post to clojure google groups this same question)

  • #2
    Dependency injection ~ Partial Function Application

    Hi Hari,

    A functional language like Clojure treats functions as first class entities. Internally the functions are turned into classes (in bytecode) but they have random class names. Getting Clojure to generate pre-known classnames is a pain (needs `gen-class`).

    Secondly, Clojure has excellent Java interoperability but the philosophy is fundamentally different. Clojure uses higher order functions and partial function application to achieve what we do in Java using dependency injection. Hence Spring's dependency injection and AOP may not be useful for Clojure, IMHO.

    However, the other parts of Spring stack can be very useful for building Clojure applications. The integration between Spring and Clojure may benefit from a different approach. For example, take a look at the Clojure/Spring-JDBC integration project I am working on here:



    • #3
      In a functional language like Clojure, dependency injection essentially amounts to passing parameters to functions. A framework like Spring is basically not needed, since of course calling functions is natively supported by the language. Spring (the core container, I mean, not all the extensions) is useful in Java mainly because:

      1) Writing 'new ...' all the time is tedious and not declarative
      2) Changing the wiring of dependencies requires compilation & rebuild

      Both points are not true for Clojure, where syntax is naturally more declarative and it's easy to load code at runtime. Some specific features of Spring (e.g. bean scoping) could still come handy, but they would individually be implemented as macros or functions (think of a kind of "scoped memoize", for example).

      If instead you want to mix a little bit of Clojure code with a lot of Java beans, then Spring is probably still useful. I'm not a Clojure user (just a lurker ), but I'm not really a fan of gen-class or similar in this scenario, as it complicates the build process (even if there are tools to hide the complexity) and makes you lose the dynamic nature of Clojure (you have to recompile to get a new bean). If you just need a handful of beans with some methods implemented in Clojure, I'd write those beans in Java and manually dispatch method calls to Clojure Vars - if this is feasible/easy (as I said, I don't know Clojure well enough to tell). That way, you could redefine the functions at runtime and have your bean automagically be updated.

      Lastly, a half-OT shameless plug: I'm the author of Dynaspring, a Common Lisp library to build Spring application contexts. I think Lisp (which includes Clojure) really shines in such a scenario because it gives you all the declarativity of XML with none of its staticity. If you think Spring lacks some feature which would be useful to your application, chances are that you can implement it with very little code and have it seamlessly integrated with the configuration language. For example, you can code your own bean-defining operator that checks some application-specific invariants or provides some application-specific defaults, and so on. I'd love to see someone implementing something like that in Clojure.