Re: stuartsierra/component is oop, can clojure namespace self init to solve the dependencies?
As it sounds a lot like your definition of OOP to me.
For sure, this code relies on messages passing. It is functional in the
old sense that the messages are functions -- a usage of the word
functional that any Lisper would have understood for decades. But it is
not functional in the newer sense of immutable.
However, I avoid the things I dislike most about OOP: instantiating
objects, and having an outside Dependency Injection system that decides
what the dependencies of this code should be. As much as possible, I try to
write start and stop functions that take responsibility for initiating
whatever needs to be initiated for this namespace.
So it sounds like you went and re-built component, but this time
around message passing, and mutable actors.
And without records, which was the thing I felt was unnecessary in
Component.
A slightly simplified example:
(ns mercury.message-queue
(:require
[mercury.datastore :as datastore]
[manifold.stream :as stream]
[manifold.deferred :as deferred]
[taoensso.timbre :as timbre]
[clojure.test :as test]))
(def ^:private message-stream (atom nil))
(defn enqueue
[message eventual-result]
{:pre [
(keyword? (:field-to-sort-by message))
(number? (:offset message))
(number? (:limit message))
]}
(stream/put! @message-stream
[
(fn [db-connection]
(try
(datastore/execute message db-connection)
(catch Exception e (timbre/log :trace (str The was an exception when we
tried to call the datastore layer: e)
eventual-result
]))
(defn- worker
[db-connection]
(loop [message-vector @(stream/take! @message-stream)]
(let [message-fn (first message-vector)
eventual-result (second message-vector)]
(deliver eventual-result (message-fn db-connection)))
(if (= @message-stream ::stop)
(datastore/stop db-connection)
(recur @(stream/take! @message-stream)
(defn start
[map-of-config-info]
(swap! message-stream (fn [old-stream] (stream/stream)))
(dotimes [_ 10]
(future (worker (datastore/start map-of-config-info)
(defn stop []
(swap! message-stream (fn [old-stream] ::stop)))
The start method spins up some workers and makes sure they each have a
database connection.
The stop function sets in motion events that cause each worker to shut
down its own database connection.
On Sunday, June 21, 2015 at 7:10:42 PM UTC-4, tbc++ wrote:
I'd like to see an example of this functional worker style you mention.
As it sounds a lot like your definition of OOP to me. Not to mention that
anything that talks to a queue is performing io and is therefore not
functionally pure. So it sounds like you went and re-built component, but
this time around message passing, and mutable actors.
On Sunday, June 21, 2015, Lawrence Krubner lawr...@rollioforce.com wrote:
There are ways to handle dependencies without going down the OOP route
that Stuart Sierra took. However, there are a lot of good ideas in Stuart
Sierra's Component library, and to the extent that you can borrow those
ideas, you end up with code that resembles best practice in the Clojure
community.
For me, one Big Idea that I got from Stuart Sierra is that there should
be a start method that can be called either from the REPL or from -main
(for when you app runs as a daemon). The other Big Idea I got was that
there should be functions for handling the lifecycle of all the components
in your app, so you can easily start and stop and restart. So nowadays my
core.clj tends to look like this:
(ns salesslick.core
(:gen-class)
(:require
[salesslick.start :as start]
[salesslick.stop :as stop]))
;; what you would call from the REPL to re-initate the app
(defn start []
(try
(start/start)
(catch Exception e (println e
(defn stop []
(try
(stop/stop)
(catch Exception e (println e
;; Enable command-line invocation
(defn -main [ args]
(.addShutdownHook (Runtime/getRuntime)
(Thread.
#(do (println Salesslick is shutting down)
(stop
(start))
So I can call start and stop from the REPL, or, if the app is running
as a daemon, start gets called by -main, and stop is registered as a
shutDownHook.
These are great ideas that I got from Stuart Sierra, however, I did not
feel the need to go as far toward OOP as Stuart Sierra did. And some of
things he has suggested as best practice really strike me as odd. To be
honest, some of the things he said were astonishing and went against
everything I have learned over the years. I'm thinking of what he says in
these 2 videos:
http://www.infoq.com/presentations/Clojure-Large-scale-patterns-techniques
Stuart Sierra - Components Just Enough Structure
At one point he says that Object Oriented code has the advantage that it
is obvious where you configure your code.
Wow!!!
Re: stuartsierra/component is oop, can clojure namespace self init to solve the dependencies?
I'd like to see an example of this functional worker style you mention. As it sounds a lot like your definition of OOP to me. Not to mention that anything that talks to a queue is performing io and is therefore not functionally pure. So it sounds like you went and re-built component, but this time around message passing, and mutable actors. On Sunday, June 21, 2015, Lawrence Krubner lawre...@rollioforce.com wrote: There are ways to handle dependencies without going down the OOP route that Stuart Sierra took. However, there are a lot of good ideas in Stuart Sierra's Component library, and to the extent that you can borrow those ideas, you end up with code that resembles best practice in the Clojure community. For me, one Big Idea that I got from Stuart Sierra is that there should be a start method that can be called either from the REPL or from -main (for when you app runs as a daemon). The other Big Idea I got was that there should be functions for handling the lifecycle of all the components in your app, so you can easily start and stop and restart. So nowadays my core.clj tends to look like this: (ns salesslick.core (:gen-class) (:require [salesslick.start :as start] [salesslick.stop :as stop])) ;; what you would call from the REPL to re-initate the app (defn start [] (try (start/start) (catch Exception e (println e (defn stop [] (try (stop/stop) (catch Exception e (println e ;; Enable command-line invocation (defn -main [ args] (.addShutdownHook (Runtime/getRuntime) (Thread. #(do (println Salesslick is shutting down) (stop (start)) So I can call start and stop from the REPL, or, if the app is running as a daemon, start gets called by -main, and stop is registered as a shutDownHook. These are great ideas that I got from Stuart Sierra, however, I did not feel the need to go as far toward OOP as Stuart Sierra did. And some of things he has suggested as best practice really strike me as odd. To be honest, some of the things he said were astonishing and went against everything I have learned over the years. I'm thinking of what he says in these 2 videos: http://www.infoq.com/presentations/Clojure-Large-scale-patterns-techniques Stuart Sierra - Components Just Enough Structure https://www.youtube.com/watch?v=13cmHf_kt-Q At one point he says that Object Oriented code has the advantage that it is obvious where you configure your code. Wow!!! What can I say about that!!! I have lost entire days because I was dragged into stupid, tedious meetings whose subject was How should we refactor these fat Rails models? I've been dragged into incredibly boring meetings to discuss Rails versus Sinatra, where the main thing under discussion was really the issue of configuration. When I am on my deathbed, looking back, I will recall some days fondly, and other days I will recall as wasted, and the most sadly wasted days of all are the days I was forced to discuss Dependency Injection with my co-workers. None of my experiences allow me to agree with Stuart Sierra that OOP makes it obvious how to configure an app. Still, without a doubt, there are good ideas in Stuart Sierra's Component library, and it is worth digging into them to find the good ideas. The place where I diverge from Stuart Sierra is in his use of Records. His main concern seems to be making dependencies visible. It's the same issue that Alex Miller focuses on here: http://tech.puredanger.com/2014/01/03/clojure-dependency-injection/ My own preference for making dependancies obvious is to use :pre assertions. I'm looking at Typed Clojure as a possibility for going further down that road. There might be use cases where it is fundamentally imperative to use something like Stuart Sierra's pseudo-OOP style, but I have not met those use cases yet. Most of the work I do tends to be the kind of thing where I can spin up some internal workers and have them pull work off a queue. I can initiate the workers from my start function and stop them with the stop function. Typically, each worker will have its own connection to 1 or more databases, and each worker takes responsibility for closing its database connections once the stop function has been called. All of this is easy to do within the Functional Paradigm. I think there is a fascinating sociological question that haunts the Clojure community, regarding OOP. Many of the best Clojure developers spent 10 or 20 years doing OOP before they came to Clojure, so how much do they bring OOP with them because they feel its natural, and they feel it natural because they spent so many years with the OOP style? On Wednesday, June 17, 2015 at 10:15:21 PM UTC-4, Xiangtao Zhou wrote: hi guys, Constructing simple clojure project is trival, just make functions. if the project grows large, with more datasources, message queue, and other storages,
Re: stuartsierra/component is oop, can clojure namespace self init to solve the dependencies?
There are ways to handle dependencies without going down the OOP route that Stuart Sierra took. However, there are a lot of good ideas in Stuart Sierra's Component library, and to the extent that you can borrow those ideas, you end up with code that resembles best practice in the Clojure community. For me, one Big Idea that I got from Stuart Sierra is that there should be a start method that can be called either from the REPL or from -main (for when you app runs as a daemon). The other Big Idea I got was that there should be functions for handling the lifecycle of all the components in your app, so you can easily start and stop and restart. So nowadays my core.clj tends to look like this: (ns salesslick.core (:gen-class) (:require [salesslick.start :as start] [salesslick.stop :as stop])) ;; what you would call from the REPL to re-initate the app (defn start [] (try (start/start) (catch Exception e (println e (defn stop [] (try (stop/stop) (catch Exception e (println e ;; Enable command-line invocation (defn -main [ args] (.addShutdownHook (Runtime/getRuntime) (Thread. #(do (println Salesslick is shutting down) (stop (start)) So I can call start and stop from the REPL, or, if the app is running as a daemon, start gets called by -main, and stop is registered as a shutDownHook. These are great ideas that I got from Stuart Sierra, however, I did not feel the need to go as far toward OOP as Stuart Sierra did. And some of things he has suggested as best practice really strike me as odd. To be honest, some of the things he said were astonishing and went against everything I have learned over the years. I'm thinking of what he says in these 2 videos: http://www.infoq.com/presentations/Clojure-Large-scale-patterns-techniques https://www.youtube.com/watch?v=13cmHf_kt-Q At one point he says that Object Oriented code has the advantage that it is obvious where you configure your code. Wow!!! What can I say about that!!! I have lost entire days because I was dragged into stupid, tedious meetings whose subject was How should we refactor these fat Rails models? I've been dragged into incredibly boring meetings to discuss Rails versus Sinatra, where the main thing under discussion was really the issue of configuration. When I am on my deathbed, looking back, I will recall some days fondly, and other days I will recall as wasted, and the most sadly wasted days of all are the days I was forced to discuss Dependency Injection with my co-workers. None of my experiences allow me to agree with Stuart Sierra that OOP makes it obvious how to configure an app. Still, without a doubt, there are good ideas in Stuart Sierra's Component library, and it is worth digging into them to find the good ideas. The place where I diverge from Stuart Sierra is in his use of Records. His main concern seems to be making dependencies visible. It's the same issue that Alex Miller focuses on here: http://tech.puredanger.com/2014/01/03/clojure-dependency-injection/ My own preference for making dependancies obvious is to use :pre assertions. I'm looking at Typed Clojure as a possibility for going further down that road. There might be use cases where it is fundamentally imperative to use something like Stuart Sierra's pseudo-OOP style, but I have not met those use cases yet. Most of the work I do tends to be the kind of thing where I can spin up some internal workers and have them pull work off a queue. I can initiate the workers from my start function and stop them with the stop function. Typically, each worker will have its own connection to 1 or more databases, and each worker takes responsibility for closing its database connections once the stop function has been called. All of this is easy to do within the Functional Paradigm. I think there is a fascinating sociological question that haunts the Clojure community, regarding OOP. Many of the best Clojure developers spent 10 or 20 years doing OOP before they came to Clojure, so how much do they bring OOP with them because they feel its natural, and they feel it natural because they spent so many years with the OOP style? On Wednesday, June 17, 2015 at 10:15:21 PM UTC-4, Xiangtao Zhou wrote: hi guys, Constructing simple clojure project is trival, just make functions. if the project grows large, with more datasources, message queue, and other storages, dependencies problem is on the table. One solution is stuartsierra/component, using system to configure dependencies graph, make component and dependencies resolution separate. If we make namespace must run with code block that init the namespace, like the start method in component, is this a good way to solve the dependencies? because when the namespace is required the first time, the init block worked once. any suggestion is appreciated. - Joe -- You received this
Re: stuartsierra/component is oop, can clojure namespace self init to solve the dependencies?
OOP always talks about object (mutable or immutable) in terms of polymorphism, encapsulation and inheritance. Components library misses only inheritance, which, obviously, the killer feature in OOP. So we could say that Components library that take good ideas from OOP. If you want call something on load of module, make call to this something explicit, ie: wrap it into a function and run on your system component start explicitly. This approach will give more flexibility and control on your state. 2015-06-18 13:08 GMT+03:00 Xiangtao Zhou tao...@gmail.com: oop means object oriented programming, which doesn't mean mutable. record is oop and immutable. when you use java, you can asume everthing is immutable. if i use dynamic to implement the object, i can test it with binding; others i can test with with-redefs. so it works, except side effects. On Thursday, June 18, 2015 at 5:21:46 PM UTC+8, Atamert Ölçgen wrote: How is stuartsierra/component OOP when it is building an immutable object graph? (Contrast that to Guava etc.) On Thu, Jun 18, 2015 at 5:15 AM, Xiangtao Zhou tao...@gmail.com wrote: hi guys, Constructing simple clojure project is trival, just make functions. if the project grows large, with more datasources, message queue, and other storages, dependencies problem is on the table. One solution is stuartsierra/component, using system to configure dependencies graph, make component and dependencies resolution separate. If we make namespace must run with code block that init the namespace, like the start method in component, is this a good way to solve the dependencies? You can do that. But it's not a really good idea to have top-level side-effectful code within namespaces. How are you going to test that ns? How will you do (stop)? Namespaces should only define things. because when the namespace is required the first time, the init block worked once. any suggestion is appreciated. - Joe -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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/d/optout. -- Best regards, Serhii Nechyporchuk -- 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/d/optout.
Re: stuartsierra/component is oop, can clojure namespace self init to solve the dependencies?
All objects can as well be implemented with message passing, a functional technique. However, if one would do it with stuartsierra/component, it would be so trivial that you could hardly call the lib object orientated. On Friday, June 19, 2015 at 11:14:04 AM UTC+2, Serzh Nechyporchuk wrote: OOP always talks about object (mutable or immutable) in terms of polymorphism, encapsulation and inheritance. Components library misses only inheritance, which, obviously, the killer feature in OOP. So we could say that Components library that take good ideas from OOP. If you want call something on load of module, make call to this something explicit, ie: wrap it into a function and run on your system component start explicitly. This approach will give more flexibility and control on your state. 2015-06-18 13:08 GMT+03:00 Xiangtao Zhou tao...@gmail.com javascript:: oop means object oriented programming, which doesn't mean mutable. record is oop and immutable. when you use java, you can asume everthing is immutable. if i use dynamic to implement the object, i can test it with binding; others i can test with with-redefs. so it works, except side effects. On Thursday, June 18, 2015 at 5:21:46 PM UTC+8, Atamert Ölçgen wrote: How is stuartsierra/component OOP when it is building an immutable object graph? (Contrast that to Guava etc.) On Thu, Jun 18, 2015 at 5:15 AM, Xiangtao Zhou tao...@gmail.com wrote: hi guys, Constructing simple clojure project is trival, just make functions. if the project grows large, with more datasources, message queue, and other storages, dependencies problem is on the table. One solution is stuartsierra/component, using system to configure dependencies graph, make component and dependencies resolution separate. If we make namespace must run with code block that init the namespace, like the start method in component, is this a good way to solve the dependencies? You can do that. But it's not a really good idea to have top-level side-effectful code within namespaces. How are you going to test that ns? How will you do (stop)? Namespaces should only define things. because when the namespace is required the first time, the init block worked once. any suggestion is appreciated. - Joe -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- Best regards, Serhii Nechyporchuk -- 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/d/optout.
Re: stuartsierra/component is oop, can clojure namespace self init to solve the dependencies?
OOP does not mean mutab... erh... anything, really, but there is an argument to be made for calling an immutable blob that carries data and the operations to act on it an immutable object. If every mutative operation returns a modified copy of the object, you can have immutable OOP. On Thursday, 18 June 2015, Atamert Ölçgen mu...@muhuk.com wrote: How is stuartsierra/component OOP when it is building an immutable object graph? (Contrast that to Guava etc.) On Thu, Jun 18, 2015 at 5:15 AM, Xiangtao Zhou tao...@gmail.com javascript:_e(%7B%7D,'cvml','tao...@gmail.com'); wrote: hi guys, Constructing simple clojure project is trival, just make functions. if the project grows large, with more datasources, message queue, and other storages, dependencies problem is on the table. One solution is stuartsierra/component, using system to configure dependencies graph, make component and dependencies resolution separate. If we make namespace must run with code block that init the namespace, like the start method in component, is this a good way to solve the dependencies? You can do that. But it's not a really good idea to have top-level side-effectful code within namespaces. How are you going to test that ns? How will you do (stop)? Namespaces should only define things. because when the namespace is required the first time, the init block worked once. any suggestion is appreciated. - Joe -- 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 javascript:_e(%7B%7D,'cvml','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 javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@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 javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@googlegroups.com');. For more options, visit https://groups.google.com/d/optout. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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 javascript:_e(%7B%7D,'cvml','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 javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@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 javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@googlegroups.com');. For more options, visit https://groups.google.com/d/optout. -- 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/d/optout.
Re: stuartsierra/component is oop, can clojure namespace self init to solve the dependencies?
oop means object oriented programming, which doesn't mean mutable. record is oop and immutable. when you use java, you can asume everthing is immutable. if i use dynamic to implement the object, i can test it with binding; others i can test with with-redefs. so it works, except side effects. On Thursday, June 18, 2015 at 5:21:46 PM UTC+8, Atamert Ölçgen wrote: How is stuartsierra/component OOP when it is building an immutable object graph? (Contrast that to Guava etc.) On Thu, Jun 18, 2015 at 5:15 AM, Xiangtao Zhou tao...@gmail.com javascript: wrote: hi guys, Constructing simple clojure project is trival, just make functions. if the project grows large, with more datasources, message queue, and other storages, dependencies problem is on the table. One solution is stuartsierra/component, using system to configure dependencies graph, make component and dependencies resolution separate. If we make namespace must run with code block that init the namespace, like the start method in component, is this a good way to solve the dependencies? You can do that. But it's not a really good idea to have top-level side-effectful code within namespaces. How are you going to test that ns? How will you do (stop)? Namespaces should only define things. because when the namespace is required the first time, the init block worked once. any suggestion is appreciated. - Joe -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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/d/optout.
Re: stuartsierra/component is oop, can clojure namespace self init to solve the dependencies?
How is stuartsierra/component OOP when it is building an immutable object graph? (Contrast that to Guava etc.) On Thu, Jun 18, 2015 at 5:15 AM, Xiangtao Zhou tao...@gmail.com wrote: hi guys, Constructing simple clojure project is trival, just make functions. if the project grows large, with more datasources, message queue, and other storages, dependencies problem is on the table. One solution is stuartsierra/component, using system to configure dependencies graph, make component and dependencies resolution separate. If we make namespace must run with code block that init the namespace, like the start method in component, is this a good way to solve the dependencies? You can do that. But it's not a really good idea to have top-level side-effectful code within namespaces. How are you going to test that ns? How will you do (stop)? Namespaces should only define things. because when the namespace is required the first time, the init block worked once. any suggestion is appreciated. - Joe -- 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/d/optout. -- Kind Regards, Atamert Ölçgen ◻◼◻ ◻◻◼ ◼◼◼ www.muhuk.com -- 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/d/optout.
stuartsierra/component is oop, can clojure namespace self init to solve the dependencies?
hi guys, Constructing simple clojure project is trival, just make functions. if the project grows large, with more datasources, message queue, and other storages, dependencies problem is on the table. One solution is stuartsierra/component, using system to configure dependencies graph, make component and dependencies resolution separate. If we make namespace must run with code block that init the namespace, like the start method in component, is this a good way to solve the dependencies? because when the namespace is required the first time, the init block worked once. any suggestion is appreciated. - Joe -- 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/d/optout.
