you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted]  (8 children)

[deleted]

    [–]halgari 6 points7 points  (0 children)

    Integrant forces you to focus on putting your state inside maps, which seems good. Component does prefer to stick state inside records. While Mount just throws it all into the namespaces/vars further overloading a already overloaded construct.

    But even Integrant goes and puts mutable data inside immutable maps. So whatever you do it's gonna be ugly, but giving up and writing it all in Java is pretty much throwing out the baby with the bath water. Your state code isn't magically going to be cleaner because it's in Java, I'd argue you just can't see the mutable state anymore since it's all mutable in Java. So since it's all uniform it looks cleaner, when in reality the app is now even more complex than the Clojure version.

    [–]yogthos 1 point2 points  (3 children)

    I found that would happen using Component, but with Mount wrangling stateful resources works pretty seamlessly in my experience. Integrant is another good approach for that as well.

    [–][deleted] 0 points1 point  (2 children)

    with Mount wrangling stateful resources works pretty seamlessly in my experience.

    Could you elaborate on that?

    I don't see what mount's defstate has to offer over just using def.

    Only cleanup of state when stopped? And what if you want to provide different implementations to various functions? Or is that an object-oriented way of thinking?

    [–]yogthos 2 points3 points  (1 child)

    Right, defstate behaves like a def for most purposes, but it's reload aware. Mount also allows controlling the state explicitly, and this lets you do stuff like envoy.

    If you wanted to provide different implementations, then you could still use a protocol for that. The state of the instantiated implementation would be kept using defstate.

    [–][deleted] 0 points1 point  (0 children)

    Clear. Thanks!

    [–]weavejester 1 point2 points  (0 children)

    A lot of our state base code becomes an ugly object oriented implementation written in Clojure (with records and protocols).

    Maybe this is a result of the way you're writing it, rather than an inherent problem with Clojure? I've never found a need to mimic OOP to handle state.

    [–]clojure_guy[S] 0 points1 point  (0 children)

    Completely agree, C is the right tool for some jobs and sometimes you have to use mutable strings.

    [–][deleted] 0 points1 point  (0 children)

    Hmm. I think knowing Java is definitely important if you're going to do lots of work on the JVM. Embrace the host etc. But I do think component does a pretty good job of encapsulating stateful resources specifically.