The thing that this doc also advocates (and I am against) is manual
dependency management, your app start function must call start on its
dependencies. This not only hardcodes the dependency, but also requires the
user to think about the startup order of components on every usage.

In addition this approach doesn't support substituting alternate
implementations. During testing I often want to use a in-memory queue vs
RabbitMQ. Or perhaps I want to wire an entire system up with in-memory
queues to perform limited integration testing. Hardcoding dependencies
limits the flexibility of the app.


And this part of the doc:

"A: You see, this all idea of reusable libraries of components never worked
and it gets complicated pretty fast. See the past 20 years of OO
frameworks. Do you really want a Spring/J2EE in your beautiful Clojure app?"

Is just wrong. Perhaps across multiple projects and multiple companies
component re-use isn't as common as some would think. but within the same
company/project components are re-used a lot. Not only does this quote it
present a false dichotomy (either you have a nice Clojure app or you have
reusable components). But it is also little more than an ad-homiem attack:
"This looks like OOP, OOP is bad, therefore doing this is bad!"



On Tue, Apr 5, 2016 at 11:31 AM, James Reeves <ja...@booleanknot.com> wrote:

> On 5 April 2016 at 17:23, <rebor...@gmail.com> wrote:
>
>> Not sure it's worth to depend on a library for a defprotocol with two
>> functions. Also, still need to double check, but I think I can get rid of
>> that defprotocol.
>>
>
> Well, the advantage with using the Lifecycle protocol from Component is
> that you can make use of existing libraries.
>
> - James
>
> --
> 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.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
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.

Reply via email to