Re: Not using dependency injection - how do I share services around?

[Sean Corfield]

Korny mentioned java.jdbc and I figured that was a good in to talk
about how we use it at World Singles. Even with the old API we used a
function in a specific namespace that returned the data source (in
fact it returned a pooled data source, using c3p0). Behind the scenes,
we actually use an atom to provide a cached, singleton instance.
with-redefs allows us to mock that for testing, if needed :)

I haven't missed DI at all since moving to Clojure - after decades of
OO - and I still use it in the non-Clojure, OO code that could be
considered our "legacy" system that wraps our Clojure code.

Clojure makes me think about my dependencies and organize them in a
very clean top-to-bottom tree, with very clear divisions between
subsystems. In the OO world, DI makes you sloppy... You can have
circular dependencies. You can easily add whatever dependencies you
need. You don't have to think about it, you can work around problems
that crop up.

Does that help Colin?

Sean

On Fri, May 10, 2013 at 4:04 AM, Colin Yates  wrote:
> (newbie, getting better each day!)
>
> I assume we all know DI.  Through the use of a central registry I can
> register a service (a bean in a Spring bean factory for example).  I also
> define consumers of that service in the same registry passing in the
> configured *instance* of that service.
>
> In Clojure I have a service (i.e. a datasource) defined in its own
> namespace.  What is idiomatic Clojure?:
>
>  1) to use (defonce *data-source*...) so that every body who requires that
> ns gets the same instance?
>  2) to provide a 'get-ds' accessor which returns a new instance and rely on
> passing that service along to every function that needs it?
>  3) some other way I don't know about
>
> Option 1 seems to be less-typing, but now functions aren't pure - they
> depend upon state defined elsewhere.  I can change the binding through
> 'with-XYZ' type functions, but that isn't solving the non-explicit
> dependency between the function and the state.
>
> Option 2 means functions are still pure, but how do you prevent huge lists
> of services - i.e. if func-a calls func-b which calls func-c and func-c
> needs service-a then func-a and func-b need to access service-a.  Yuck.  It
> also means the main entry point to my application needs to assemble all of
> these services up in one go.
>
> To be more explicit - DI containers provide a graphs of logic coupled with
> state - the state being the instances of the collaborators (i.e. "I will
> have ConsumerA with an instance of SimpleServiceA please").  Clojure has
> very strong opinions about how to manage state.
>
> How does the Clojure community handle this use case of separating out the
> definition of a service, the configuration of that service and providing
> that service as a collaborator to a consumer?
>
> Thanks a bunch.
>
> Col
>
> --
> --
> 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/groups/opt_out.
>
>



-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
-- 
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/groups/opt_out.

Why is using (not (empty? coll)) not idiomatic?

[Nico Balestra]

I'm not sure this question has been asked already, but I really want to
know the "principle" behind (not (empty? coll)) not being idiomatic.

I find it much more readable than (seq coll) and I don't understand why
(empty?) exists if it's not idiomatic. But my real doubt is:

What's the "idiom" in (seq coll)?

Thanks and sorry if the question sounds a bit pedantic :)

Nico

*"It is better to have 100 functions operate on one data structure than to
have 10 functions operate on 10 data structures" - A.J. Perlis*

-- 
-- 
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/groups/opt_out.

Re: Not using dependency injection - how do I share services around?

[Chris Ford]

Sounds to me like there's enough meat in this topic for someone to consider
submitting a talk to the upcoming EuroClojure  or
Clojure/conj  on what Clojure means for DI. It's
a commonly asked question, and it could be an opportunity for The Clojure
Way (TM) to influence practices across language boundaries.


On 11 May 2013 10:21, Sean Corfield  wrote:

> Korny mentioned java.jdbc and I figured that was a good in to talk
> about how we use it at World Singles. Even with the old API we used a
> function in a specific namespace that returned the data source (in
> fact it returned a pooled data source, using c3p0). Behind the scenes,
> we actually use an atom to provide a cached, singleton instance.
> with-redefs allows us to mock that for testing, if needed :)
>
> I haven't missed DI at all since moving to Clojure - after decades of
> OO - and I still use it in the non-Clojure, OO code that could be
> considered our "legacy" system that wraps our Clojure code.
>
> Clojure makes me think about my dependencies and organize them in a
> very clean top-to-bottom tree, with very clear divisions between
> subsystems. In the OO world, DI makes you sloppy... You can have
> circular dependencies. You can easily add whatever dependencies you
> need. You don't have to think about it, you can work around problems
> that crop up.
>
> Does that help Colin?
>
> Sean
>
> On Fri, May 10, 2013 at 4:04 AM, Colin Yates 
> wrote:
> > (newbie, getting better each day!)
> >
> > I assume we all know DI.  Through the use of a central registry I can
> > register a service (a bean in a Spring bean factory for example).  I also
> > define consumers of that service in the same registry passing in the
> > configured *instance* of that service.
> >
> > In Clojure I have a service (i.e. a datasource) defined in its own
> > namespace.  What is idiomatic Clojure?:
> >
> >  1) to use (defonce *data-source*...) so that every body who requires
> that
> > ns gets the same instance?
> >  2) to provide a 'get-ds' accessor which returns a new instance and rely
> on
> > passing that service along to every function that needs it?
> >  3) some other way I don't know about
> >
> > Option 1 seems to be less-typing, but now functions aren't pure - they
> > depend upon state defined elsewhere.  I can change the binding through
> > 'with-XYZ' type functions, but that isn't solving the non-explicit
> > dependency between the function and the state.
> >
> > Option 2 means functions are still pure, but how do you prevent huge
> lists
> > of services - i.e. if func-a calls func-b which calls func-c and func-c
> > needs service-a then func-a and func-b need to access service-a.  Yuck.
>  It
> > also means the main entry point to my application needs to assemble all
> of
> > these services up in one go.
> >
> > To be more explicit - DI containers provide a graphs of logic coupled
> with
> > state - the state being the instances of the collaborators (i.e. "I will
> > have ConsumerA with an instance of SimpleServiceA please").  Clojure has
> > very strong opinions about how to manage state.
> >
> > How does the Clojure community handle this use case of separating out the
> > definition of a service, the configuration of that service and providing
> > that service as a collaborator to a consumer?
> >
> > Thanks a bunch.
> >
> > Col
> >
> > --
> > --
> > 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/groups/opt_out.
> >
> >
>
>
>
> --
> Sean A Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> World Singles, LLC. -- http://worldsingles.com/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>
> --
> --
> 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 receiv

Re: Not using dependency injection - how do I share services around?

[Colin Yates]

Yes it does, thanks.  It is amazing how much you can do in the typical
spring/hibernate stack with a decent IDE without engaging your brain :).

Clojure involves far less ceremony and really does expose you to the raw
elements of your problem domain and make you think.

This is of course a good thing, but boy is it quite humbling :).  No more
procrastinating by setting up JPA and thinking long and hard about "Java,
Annotations or good old XML?".

I am definitely at the stage where I think Clojure's simplicity is very
hard (according to Rich's "simple made easy" talk).  Not implying Clojure's
simplicity is only the lack of ceremonial frameworks!

Loving it, and yes, looking back I can see how easy it is to lose your
solution amongst the staggering amount of incidental complexity.

I guess my (rambling) point is to reiterate that it is very easy to plaster
over symptoms/effects using the very powerful framework beasts.  The lack
of them forces you to think, and hopefully remove the cause.

Finally,  I have worked with some fantastic developers who happen to use
Java to build incredibly elegant and transparent solutions.  I have just
worked with far more code monkeys, myself being one of them :).
On 11 May 2013 08:21, "Sean Corfield"  wrote:

> Korny mentioned java.jdbc and I figured that was a good in to talk
> about how we use it at World Singles. Even with the old API we used a
> function in a specific namespace that returned the data source (in
> fact it returned a pooled data source, using c3p0). Behind the scenes,
> we actually use an atom to provide a cached, singleton instance.
> with-redefs allows us to mock that for testing, if needed :)
>
> I haven't missed DI at all since moving to Clojure - after decades of
> OO - and I still use it in the non-Clojure, OO code that could be
> considered our "legacy" system that wraps our Clojure code.
>
> Clojure makes me think about my dependencies and organize them in a
> very clean top-to-bottom tree, with very clear divisions between
> subsystems. In the OO world, DI makes you sloppy... You can have
> circular dependencies. You can easily add whatever dependencies you
> need. You don't have to think about it, you can work around problems
> that crop up.
>
> Does that help Colin?
>
> Sean
>
> On Fri, May 10, 2013 at 4:04 AM, Colin Yates 
> wrote:
> > (newbie, getting better each day!)
> >
> > I assume we all know DI.  Through the use of a central registry I can
> > register a service (a bean in a Spring bean factory for example).  I also
> > define consumers of that service in the same registry passing in the
> > configured *instance* of that service.
> >
> > In Clojure I have a service (i.e. a datasource) defined in its own
> > namespace.  What is idiomatic Clojure?:
> >
> >  1) to use (defonce *data-source*...) so that every body who requires
> that
> > ns gets the same instance?
> >  2) to provide a 'get-ds' accessor which returns a new instance and rely
> on
> > passing that service along to every function that needs it?
> >  3) some other way I don't know about
> >
> > Option 1 seems to be less-typing, but now functions aren't pure - they
> > depend upon state defined elsewhere.  I can change the binding through
> > 'with-XYZ' type functions, but that isn't solving the non-explicit
> > dependency between the function and the state.
> >
> > Option 2 means functions are still pure, but how do you prevent huge
> lists
> > of services - i.e. if func-a calls func-b which calls func-c and func-c
> > needs service-a then func-a and func-b need to access service-a.  Yuck.
>  It
> > also means the main entry point to my application needs to assemble all
> of
> > these services up in one go.
> >
> > To be more explicit - DI containers provide a graphs of logic coupled
> with
> > state - the state being the instances of the collaborators (i.e. "I will
> > have ConsumerA with an instance of SimpleServiceA please").  Clojure has
> > very strong opinions about how to manage state.
> >
> > How does the Clojure community handle this use case of separating out the
> > definition of a service, the configuration of that service and providing
> > that service as a collaborator to a consumer?
> >
> > Thanks a bunch.
> >
> > Col
> >
> > --
> > --
> > 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/groups/o

Re: Not using dependency injection - how do I share services around?

[Jimmy]

Do any of the clojure books cover this topic?

-- 
-- 
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/groups/opt_out.

Re: Not using dependency injection - how do I share services around?

[Jimmy]

Do any of the clojure books cover this topic?

-- 
-- 
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/groups/opt_out.

Re: Why is using (not (empty? coll)) not idiomatic?

[Kelker Ryan]

(seq coll) will return a true value if the collection isn't empty. It will also 
return nil (false) if it is.

11.05.2013, 17:37, "Nico Balestra" :
> I'm not sure this question has been asked already, but I really want to know 
> the "principle" behind (not (empty? coll)) not being idiomatic.
>
> I find it much more readable than (seq coll) and I don't understand why 
> (empty?) exists if it's not idiomatic. But my real doubt is:
>
> What's the "idiom" in (seq coll)?
>
> Thanks and sorry if the question sounds a bit pedantic :)
>
> Nico
>
> "It is better to have 100 functions operate on one data structure than to 
> have 10 functions operate on 10 data structures" - A.J. Perlis
>
> --
> --
> 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/groups/opt_out.

-- 
-- 
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/groups/opt_out.

Re: Why is using (not (empty? coll)) not idiomatic?

[Kelker Ryan]

Here's an example.

user=> (if (seq []) (println 1))
nil
user=> (if (seq [1]) (println 1))
1
nil


11.05.2013, 18:40, "Kelker Ryan"
> (seq coll) will return a true value if the collection isn't empty. It will 
> also return nil (false) if it is.
>
> 11.05.2013, 17:37, "Nico Balestra" :
>
>>  I'm not sure this question has been asked already, but I really want to 
>> know the "principle" behind (not (empty? coll)) not being idiomatic.
>>
>>  I find it much more readable than (seq coll) and I don't understand why 
>> (empty?) exists if it's not idiomatic. But my real doubt is:
>>
>>  What's the "idiom" in (seq coll)?
>>
>>  Thanks and sorry if the question sounds a bit pedantic :)
>>
>>  Nico
>>
>>  "It is better to have 100 functions operate on one data structure than to 
>> have 10 functions operate on 10 data structures" - A.J. Perlis
>>
>>  --
>>  --
>>  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/groups/opt_out.
>
> --
> --
> 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/groups/opt_out.

-- 
-- 
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/groups/opt_out.

Re: Why is using (not (empty? coll)) not idiomatic?

[Chris Ford]

IMHO it's a bit subjective, but empty? is defined as (not (seq coll)), so
using (not (empty? coll)) is really saying (not (not (seq coll))), which
feels a bit backwards.

Using seq also plays nicely with if-let:

(if-let [foo (seq "hey")] (print foo))
(if-let [foo (seq "")] (print foo))

Chris


On 11 May 2013 12:48, Kelker Ryan  wrote:

> Here's an example.
>
> user=> (if (seq []) (println 1))
> nil
> user=> (if (seq [1]) (println 1))
> 1
> nil
>
>
> 11.05.2013, 18:40, "Kelker Ryan"
> > (seq coll) will return a true value if the collection isn't empty. It
> will also return nil (false) if it is.
> >
> > 11.05.2013, 17:37, "Nico Balestra" :
> >
> >>  I'm not sure this question has been asked already, but I really want
> to know the "principle" behind (not (empty? coll)) not being idiomatic.
> >>
> >>  I find it much more readable than (seq coll) and I don't understand
> why (empty?) exists if it's not idiomatic. But my real doubt is:
> >>
> >>  What's the "idiom" in (seq coll)?
> >>
> >>  Thanks and sorry if the question sounds a bit pedantic :)
> >>
> >>  Nico
> >>
> >>  "It is better to have 100 functions operate on one data structure than
> to have 10 functions operate on 10 data structures" - A.J. Perlis
> >>
> >>  --
> >>  --
> >>  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/groups/opt_out.
> >
> > --
> > --
> > 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/groups/opt_out.
>
> --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: Not using dependency injection - how do I share services around?

[abp]

Well, you could also watch Stuart Sierras talks on structuring functional 
programs:

Clojure in the Large
http://vimeo.com/46163090

Thinking in Data & Functional Design Patterns
http://www.infoq.com/author/Stuart-Sierra

On Saturday, May 11, 2013 10:48:02 AM UTC+2, Colin Yates wrote:
>
> Yes it does, thanks.  It is amazing how much you can do in the typical 
> spring/hibernate stack with a decent IDE without engaging your brain :).  
>
> Clojure involves far less ceremony and really does expose you to the raw 
> elements of your problem domain and make you think.
>
> This is of course a good thing, but boy is it quite humbling :).  No more 
> procrastinating by setting up JPA and thinking long and hard about "Java, 
> Annotations or good old XML?".
>
> I am definitely at the stage where I think Clojure's simplicity is very 
> hard (according to Rich's "simple made easy" talk).  Not implying Clojure's 
> simplicity is only the lack of ceremonial frameworks!
>
> Loving it, and yes, looking back I can see how easy it is to lose your 
> solution amongst the staggering amount of incidental complexity.
>
> I guess my (rambling) point is to reiterate that it is very easy to 
> plaster over symptoms/effects using the very powerful framework beasts.  
> The lack of them forces you to think, and hopefully remove the cause.
>
> Finally,  I have worked with some fantastic developers who happen to use 
> Java to build incredibly elegant and transparent solutions.  I have just 
> worked with far more code monkeys, myself being one of them :).
> On 11 May 2013 08:21, "Sean Corfield" > 
> wrote:
>
>> Korny mentioned java.jdbc and I figured that was a good in to talk
>> about how we use it at World Singles. Even with the old API we used a
>> function in a specific namespace that returned the data source (in
>> fact it returned a pooled data source, using c3p0). Behind the scenes,
>> we actually use an atom to provide a cached, singleton instance.
>> with-redefs allows us to mock that for testing, if needed :)
>>
>> I haven't missed DI at all since moving to Clojure - after decades of
>> OO - and I still use it in the non-Clojure, OO code that could be
>> considered our "legacy" system that wraps our Clojure code.
>>
>> Clojure makes me think about my dependencies and organize them in a
>> very clean top-to-bottom tree, with very clear divisions between
>> subsystems. In the OO world, DI makes you sloppy... You can have
>> circular dependencies. You can easily add whatever dependencies you
>> need. You don't have to think about it, you can work around problems
>> that crop up.
>>
>> Does that help Colin?
>>
>> Sean
>>
>> On Fri, May 10, 2013 at 4:04 AM, Colin Yates 
>> > 
>> wrote:
>> > (newbie, getting better each day!)
>> >
>> > I assume we all know DI.  Through the use of a central registry I can
>> > register a service (a bean in a Spring bean factory for example).  I 
>> also
>> > define consumers of that service in the same registry passing in the
>> > configured *instance* of that service.
>> >
>> > In Clojure I have a service (i.e. a datasource) defined in its own
>> > namespace.  What is idiomatic Clojure?:
>> >
>> >  1) to use (defonce *data-source*...) so that every body who requires 
>> that
>> > ns gets the same instance?
>> >  2) to provide a 'get-ds' accessor which returns a new instance and 
>> rely on
>> > passing that service along to every function that needs it?
>> >  3) some other way I don't know about
>> >
>> > Option 1 seems to be less-typing, but now functions aren't pure - they
>> > depend upon state defined elsewhere.  I can change the binding through
>> > 'with-XYZ' type functions, but that isn't solving the non-explicit
>> > dependency between the function and the state.
>> >
>> > Option 2 means functions are still pure, but how do you prevent huge 
>> lists
>> > of services - i.e. if func-a calls func-b which calls func-c and func-c
>> > needs service-a then func-a and func-b need to access service-a.  Yuck. 
>>  It
>> > also means the main entry point to my application needs to assemble all 
>> of
>> > these services up in one go.
>> >
>> > To be more explicit - DI containers provide a graphs of logic coupled 
>> with
>> > state - the state being the instances of the collaborators (i.e. "I will
>> > have ConsumerA with an instance of SimpleServiceA please").  Clojure has
>> > very strong opinions about how to manage state.
>> >
>> > How does the Clojure community handle this use case of separating out 
>> the
>> > definition of a service, the configuration of that service and providing
>> > that service as a collaborator to a consumer?
>> >
>> > Thanks a bunch.
>> >
>> > Col
>> >
>> > --
>> > --
>> > 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 g

Clojure Web Framework

[Kelker Ryan]

There's now an example and a tutorial for using the CHP web framework.CHP - https://github.com/runexec/chpWork with HTML, CSS, _javascript_, and SQL using Clojure. 



-- 
-- 
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/groups/opt_out.
 
 

[ANN] core.typed 0.1.14

[Ambrose Bonnaire-Sergeant]

Hi,

Announcing a new release of core.typed, with a bunch of improvements and
fixes.

Leiningen: [org.clojure/core.typed "0.1.14"]

Highlights:
- support optional & mandatory function keyword arguments
- def-alias takes a docstring, and adds appropriate :doc metadata to the
alias var.
- accumulates and displays multiple type errors per run
- heterogeneous maps can track known absent keys
- supports letfn via letfn>

See changes for 0.1.14:
https://github.com/clojure/core.typed/blob/master/CHANGELOG.md

Thanks,
Ambrose

-- 
-- 
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/groups/opt_out.

Re: [ANN] core.typed 0.1.14

[Max Penet]

Hi, 

Some nice improvements here, thanks!

- Max

On Saturday, May 11, 2013 3:53:02 PM UTC+2, Ambrose Bonnaire-Sergeant wrote:
>
> Hi,
>
> Announcing a new release of core.typed, with a bunch of improvements and 
> fixes.
>
> Leiningen: [org.clojure/core.typed "0.1.14"]
>
> Highlights:
> - support optional & mandatory function keyword arguments
> - def-alias takes a docstring, and adds appropriate :doc metadata to the 
> alias var.
> - accumulates and displays multiple type errors per run
> - heterogeneous maps can track known absent keys
> - supports letfn via letfn>
>
> See changes for 0.1.14: 
> https://github.com/clojure/core.typed/blob/master/CHANGELOG.md
>
> Thanks,
> Ambrose
>

-- 
-- 
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/groups/opt_out.

Re: [ANN] core.typed 0.1.14

[Ambrose Bonnaire-Sergeant]

Thanks! I'll be open sourcing a hobby project in the next few days that
shows off these features.

Ambrose


On Sat, May 11, 2013 at 10:12 PM, Max Penet  wrote:

> Hi,
>
> Some nice improvements here, thanks!
>
> - Max
>
> On Saturday, May 11, 2013 3:53:02 PM UTC+2, Ambrose Bonnaire-Sergeant
> wrote:
>>
>> Hi,
>>
>> Announcing a new release of core.typed, with a bunch of improvements and
>> fixes.
>>
>> Leiningen: [org.clojure/core.**typed "0.1.14"]
>>
>> Highlights:
>> - support optional & mandatory function keyword arguments
>> - def-alias takes a docstring, and adds appropriate :doc metadata to the
>> alias var.
>> - accumulates and displays multiple type errors per run
>> - heterogeneous maps can track known absent keys
>> - supports letfn via letfn>
>>
>> See changes for 0.1.14: https://github.com/**clojure/core.typed/blob/**
>> master/CHANGELOG.md
>>
>> Thanks,
>> Ambrose
>>
>

-- 
-- 
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/groups/opt_out.

FTP with Clojure on Heroku

[Jonathon McKitrick]

I did some googling today, and didn't find much specifically for Clojure, 
and most of what I did find was a bit stale.

Has anyone had any success accepting FTP uploads in Clojure on Heroku?

-- 
-- 
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/groups/opt_out.

Clojure performance measuring

[Jonathon McKitrick]

If I cannot get New Relic to work, I'm going to stick to my development 
platform for initial optimization and memory troubleshooting.

What tools do you recommend for profiling memory under Clojure?  I didn't 
have much luck with VisualVM, since my Mac is a bit dated at this point, 
but I'd be willing to try again with a decent tutorial.

-- 
-- 
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/groups/opt_out.

Re: Why is using (not (empty? coll)) not idiomatic?

[Karsten Schmidt]

>  What's the "idiom" in (seq coll)?

Maybe one could say that, generally, in Clojure it's more meaningful
to work with truthy values instead of the boolean true... ?

-- 
-- 
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/groups/opt_out.

Re: Why is using (not (empty? coll)) not idiomatic?

[Alex Baranosky]

Most of the code I see and write at work at Runa uses (not (empty? foo)).
 I'll continue to defend the position that it is more obvious code, and
therefore better (imo :) )

Alex

On Sat, May 11, 2013 at 12:22 PM, Karsten Schmidt  wrote:

> >  What's the "idiom" in (seq coll)?
>
> Maybe one could say that, generally, in Clojure it's more meaningful
> to work with truthy values instead of the boolean true... ?
>
> --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: Not using dependency injection - how do I share services around?

[Colin Yates]

Not specifically, nope.
On 11 May 2013 10:37, "Jimmy"  wrote:

> Do any of the clojure books cover this topic?
>
> --
> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/keid7IGzKjk/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: Why is using (not (empty? coll)) not idiomatic?

[Jonathan Fischer Friberg]

On Sat, May 11, 2013 at 9:25 PM, Alex Baranosky <
alexander.barano...@gmail.com> wrote:

> Most of the code I see and write at work at Runa uses (not (empty? foo)).
>  I'll continue to defend the position that it is more obvious code, and
> therefore better (imo :) )
>
> Alex
>

Completely agree. (seq foo) says "nothing", but (empty? foo) says exactly
what's going on.

Jonathan

-- 
-- 
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/groups/opt_out.

Re: Why is using (not (empty? coll)) not idiomatic?

[Sean Corfield]

But then instead of

(if (not (empty? foo))
  (do-something-to foo)
  base-expr)

you could just write

(if (empty? foo)
  base-expr
  (do-something-to foo))

which maintains the "idiomatic" approach but is still "more obvious code", yes?

Sean


On Sat, May 11, 2013 at 2:20 PM, Jonathan Fischer Friberg
 wrote:
> On Sat, May 11, 2013 at 9:25 PM, Alex Baranosky
>  wrote:
>>
>> Most of the code I see and write at work at Runa uses (not (empty? foo)).
>> I'll continue to defend the position that it is more obvious code, and
>> therefore better (imo :) )
>>
>> Alex
>
>
> Completely agree. (seq foo) says "nothing", but (empty? foo) says exactly
> what's going on.
>
> Jonathan
>
> --
> --
> 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/groups/opt_out.
>
>



-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
-- 
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/groups/opt_out.

Re: Why is using (not (empty? coll)) not idiomatic?

[AtKaaZ]

I agree


On Sat, May 11, 2013 at 10:25 PM, Alex Baranosky <
alexander.barano...@gmail.com> wrote:

> Most of the code I see and write at work at Runa uses (not (empty? foo)).
>  I'll continue to defend the position that it is more obvious code, and
> therefore better (imo :) )
>
> Alex
>
>
> On Sat, May 11, 2013 at 12:22 PM, Karsten Schmidt  wrote:
>
>> >  What's the "idiom" in (seq coll)?
>>
>> Maybe one could say that, generally, in Clojure it's more meaningful
>> to work with truthy values instead of the boolean true... ?
>>
>> --
>> --
>> 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/groups/opt_out.
>>
>>
>>
>  --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: Why is using (not (empty? coll)) not idiomatic?

[Alex Baranosky]

Sean,

I'd tend to write things like that, yeah.

On Sat, May 11, 2013 at 2:49 PM, AtKaaZ  wrote:

> I agree
>
>
> On Sat, May 11, 2013 at 10:25 PM, Alex Baranosky <
> alexander.barano...@gmail.com> wrote:
>
>> Most of the code I see and write at work at Runa uses (not (empty? foo)).
>>  I'll continue to defend the position that it is more obvious code, and
>> therefore better (imo :) )
>>
>> Alex
>>
>>
>> On Sat, May 11, 2013 at 12:22 PM, Karsten Schmidt wrote:
>>
>>> >  What's the "idiom" in (seq coll)?
>>>
>>> Maybe one could say that, generally, in Clojure it's more meaningful
>>> to work with truthy values instead of the boolean true... ?
>>>
>>> --
>>> --
>>> 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/groups/opt_out.
>>>
>>>
>>>
>>  --
>> --
>> 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/groups/opt_out.
>>
>>
>>
>
>  --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: Why is using (not (empty? coll)) not idiomatic?

[Rob Lachlan]

Doesn't anyone use "not-empty"?

http://clojuredocs.org/clojure_core/clojure.core/not-empty


On Saturday, May 11, 2013 1:36:57 AM UTC-7, Nico Balestra wrote:
>
> I'm not sure this question has been asked already, but I really want to 
> know the "principle" behind (not (empty? coll)) not being idiomatic.
>
> I find it much more readable than (seq coll) and I don't understand why 
> (empty?) exists if it's not idiomatic. But my real doubt is:
>
> What's the "idiom" in (seq coll)?
>
> Thanks and sorry if the question sounds a bit pedantic :)
>
> Nico
>
> *"It is better to have 100 functions operate on one data structure than 
> to have 10 functions operate on 10 data structures" - A.J. Perlis*
>  

-- 
-- 
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/groups/opt_out.

js->clj not working

[nchurch]

I'm trying to get a map out of a Goog events object (and also out of
Domina events objects).  Calling js->clj on either of these, even in
the most recent version of cljs, doesn't seem to do anything; it just
returns the inscrutable #<[object Object]> at the REPL.  (It doesn't
seem to produce maps outside the REPL either, since a console.log of a
lookup on the result of js->clj returns an unimplemented protocol
error.)

Is there a problem with js->clj, or is there perhaps a limitation on
what kinds of js objects it can handle?

Thanks,

Nick.

-- 
-- 
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/groups/opt_out.

Re: Not using dependency injection - how do I share services around?

[Jason Wolfe]

Hi Colin,

This is one of the reasons we created graph:

https://github.com/prismatic/plumbing

which is a general declarative mechanism for describing complex function 
compositions.  There's not an awesome public example yet, but we use Graph 
at Prismatic to build our production services, where each node builds a 
single component of a service, based on other named other components and 
parameters.  This ends up looking somewhat similar to dependency injection, 
although the details are rather different.  Basically you get the 
advantages of your second option (no global state), but hopefully without 
the 'yuck'.

If you're interested, I'm happy to answer questions here or on the plumbing 
mailing list:

https://groups.google.com/forum/#!forum/prismatic-plumbing

Cheers,
Jason

On Friday, May 10, 2013 4:04:20 AM UTC-7, Colin Yates wrote:
>
> (newbie, getting better each day!)
>
> I assume we all know DI.  Through the use of a central registry I can 
> register a service (a bean in a Spring bean factory for example).  I also 
> define consumers of that service in the same registry passing in the 
> configured *instance* of that service.
>
> In Clojure I have a service (i.e. a datasource) defined in its own 
> namespace.  What is idiomatic Clojure?:
>
>  1) to use (defonce *data-source*...) so that every body who requires that 
> ns gets the same instance?
>  2) to provide a 'get-ds' accessor which returns a new instance and rely 
> on passing that service along to every function that needs it?
>  3) some other way I don't know about
>
> Option 1 seems to be less-typing, but now functions aren't pure - they 
> depend upon state defined elsewhere.  I can change the binding through 
> 'with-XYZ' type functions, but that isn't solving the non-explicit 
> dependency between the function and the state.
>
> Option 2 means functions are still pure, but how do you prevent huge lists 
> of services - i.e. if func-a calls func-b which calls func-c and func-c 
> needs service-a then func-a and func-b need to access service-a.  Yuck.  It 
> also means the main entry point to my application needs to assemble all of 
> these services up in one go.
>
> To be more explicit - DI containers provide a graphs of logic coupled with 
> state - the state being the instances of the collaborators (i.e. "I will 
> have ConsumerA with an instance of SimpleServiceA please").  Clojure has 
> very strong opinions about how to manage state.  
>
> How does the Clojure community handle this use case of separating out the 
> definition of a service, the configuration of that service and providing 
> that service as a collaborator to a consumer?
>
> Thanks a bunch.
>
> Col
>

-- 
-- 
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/groups/opt_out.

Released lein-cljsbuild 0.3.1

[Evan Mezeske]

Nothing major in this release other than some bugfixes and bringing the 
default ClojureScript version up to date.  Thanks to all contributors! 
 Release notes:

https://github.com/emezeske/lein-cljsbuild/blob/master/doc/RELEASE-NOTES.md

-Evan

-- 
-- 
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/groups/opt_out.

support for annotations on method parameters

[fmjrey]

I was wondering if there was any particular reason or difficulty that would 
explain why annotations on method parameters are not yet supported.
These are quite useful in many frameworks, e.g. parameter injection, 
observers, eclipse e4 event 
handling.
 
In the latter case which interests me there's no other way around 
annotations.
After a couple hours looking around, I found no elegant solution for 
writing event handlers in clojure, I will have to write them in java. Which 
is sad because event handling is a typical case where closures are of great 
value.
What would it take to implement the support for annotations in method 
parameters?
Being new to e4 and clojure I may have missed something, so I'll be glad 
for any pointers.

-- 
-- 
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/groups/opt_out.

Bug in transients: Cannot add more than 8 items to a transient map

[Wojciech Winogrodzki]

Clojure 1.5.1.

I'm trying to reorder a map. The keys in the map are known beforehand and 
their order is undefined. So, I'm taking this map and construct a new 
transient map with the keys ordered as I need them:

defn reorder-map []
  (let [
m {:j 10 :g 7 :b 2 :d 4 :e 5 :h 8 :i 9 :f 6 :c 3 :a 1 }
kwds [:a :b :c :d :e :f :g :h :i :j]
temp (transient {})
]
(doseq [k kwds]
  (assoc! temp k (m k)))
(persistent! temp)))

It returns {:a 1, :b 2, :c 3, :d 4, :e 5, :f 6, :g 7, :h 8}. The order is 
as I have defined, but there are *only 8 out of 10 items* in the new map.

If I do the same with an atom, all items are taken into account, but the 
order is not as expected:

(defn reorder-map-2 []
  (let [
a (atom {})
m {:j 10 :g 7 :b 2 :d 4 :e 5 :h 8 :i 9 :f 6 :c 3 :a 1 }
kwds [:a :b :c :d :e :f :g :h :i :j]
]
(doseq [k kwds]
  (swap!  a assoc k (m k)))
@a))

It returns {:a 1, :c 3, :b 2, :f 6, :g 7, :d 4, :e 5, :j 10, :i 9, :h 8}

I don't know the internals to judge in which order items are associated in 
a map. It seems that normal association prepends; transient association 
appends; atom association does not obey any particular order.

Anyway,* it seems to be a bug in that the transient didn't accept more than 
8 items*. It should, I suppose.

Or am I doing sth. very wrong?

Thank you -






-- 
-- 
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/groups/opt_out.

Re: Bug in transients: Cannot add more than 8 items to a transient map

[Andy Fingerhut]

What you are attempting to do is sometimes called "bashing a transient in
place".  See these links for some discussion and examples:

http://clojuredocs.org/clojure_core/clojure.core/assoc!
http://clojuredocs.org/clojure_core/clojure.core/dissoc!

Andy



On Sat, May 11, 2013 at 3:51 PM, Wojciech Winogrodzki <
wwinogrod...@gmail.com> wrote:

> Clojure 1.5.1.
>
> I'm trying to reorder a map. The keys in the map are known beforehand and
> their order is undefined. So, I'm taking this map and construct a new
> transient map with the keys ordered as I need them:
>
> defn reorder-map []
>   (let [
> m {:j 10 :g 7 :b 2 :d 4 :e 5 :h 8 :i 9 :f 6 :c 3 :a 1 }
> kwds [:a :b :c :d :e :f :g :h :i :j]
> temp (transient {})
> ]
> (doseq [k kwds]
>   (assoc! temp k (m k)))
> (persistent! temp)))
>
> It returns {:a 1, :b 2, :c 3, :d 4, :e 5, :f 6, :g 7, :h 8}. The order is
> as I have defined, but there are *only 8 out of 10 items* in the new map.
>
> If I do the same with an atom, all items are taken into account, but the
> order is not as expected:
>
> (defn reorder-map-2 []
>   (let [
> a (atom {})
> m {:j 10 :g 7 :b 2 :d 4 :e 5 :h 8 :i 9 :f 6 :c 3 :a 1 }
> kwds [:a :b :c :d :e :f :g :h :i :j]
> ]
> (doseq [k kwds]
>   (swap!  a assoc k (m k)))
> @a))
>
> It returns {:a 1, :c 3, :b 2, :f 6, :g 7, :d 4, :e 5, :j 10, :i 9, :h 8}
>
> I don't know the internals to judge in which order items are associated in
> a map. It seems that normal association prepends; transient association
> appends; atom association does not obey any particular order.
>
> Anyway,* it seems to be a bug in that the transient didn't accept more
> than 8 items*. It should, I suppose.
>
> Or am I doing sth. very wrong?
>
> Thank you -
>
>
>
>
>
>
>  --
> --
> 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/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: Why is using (not (empty? coll)) not idiomatic?

[Jean Niklas L'orange]

On Saturday, May 11, 2013 11:28:34 PM UTC+2, Sean Corfield wrote:

> you could just write [...]
>

In some cases, this is even more readable:  

(if-not (empty? foo)
  (do-something-to foo) 
  base-expr)

which has the same effect, but in some cases, having (do-something-to foo) 
first 
may be more readable than having base-expr first.

I'd generally write code as evident as possible. (if-not (empty? x) is a 
recurring pattern as I feel it conveys its purpose better than (if (seq x), 
but I suppose that's preference.

-- JN

-- 
-- 
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/groups/opt_out.

Re: Bug in transients: Cannot add more than 8 items to a transient map

[Alan Malloy]

Also, maps don't have an ordering, so the function is misguided by 
definition. You can use a sorted-map, if having the map's keys is very 
important to you, but generally it's just confusion that leads to wanting 
this in the first place.

If you do decide the map must be sorted in a specific order, you could use 
something like 
https://github.com/flatland/useful/blob/develop/src/flatland/useful/map.clj#L222
 to 
create a sorted map whose comparator function knows about the ordering you 
want: (into (ordering-map [:a :b :c :d]) m), for example.

On Saturday, May 11, 2013 5:41:25 PM UTC-7, Andy Fingerhut wrote:
>
> What you are attempting to do is sometimes called "bashing a transient in 
> place".  See these links for some discussion and examples:
>
> http://clojuredocs.org/clojure_core/clojure.core/assoc!
> http://clojuredocs.org/clojure_core/clojure.core/dissoc!
>
> Andy
>
>
>
> On Sat, May 11, 2013 at 3:51 PM, Wojciech Winogrodzki 
> 
> > wrote:
>
>> Clojure 1.5.1.
>>
>> I'm trying to reorder a map. The keys in the map are known beforehand and 
>> their order is undefined. So, I'm taking this map and construct a new 
>> transient map with the keys ordered as I need them:
>>
>> defn reorder-map []
>>   (let [
>> m {:j 10 :g 7 :b 2 :d 4 :e 5 :h 8 :i 9 :f 6 :c 3 :a 1 }
>> kwds [:a :b :c :d :e :f :g :h :i :j]
>> temp (transient {})
>> ]
>> (doseq [k kwds]
>>   (assoc! temp k (m k)))
>> (persistent! temp)))
>>
>> It returns {:a 1, :b 2, :c 3, :d 4, :e 5, :f 6, :g 7, :h 8}. The order is 
>> as I have defined, but there are *only 8 out of 10 items* in the new map.
>>
>> If I do the same with an atom, all items are taken into account, but the 
>> order is not as expected:
>>
>> (defn reorder-map-2 []
>>   (let [
>> a (atom {})
>> m {:j 10 :g 7 :b 2 :d 4 :e 5 :h 8 :i 9 :f 6 :c 3 :a 1 }
>> kwds [:a :b :c :d :e :f :g :h :i :j]
>> ]
>> (doseq [k kwds]
>>   (swap!  a assoc k (m k)))
>> @a))
>>
>> It returns {:a 1, :c 3, :b 2, :f 6, :g 7, :d 4, :e 5, :j 10, :i 9, :h 8}
>>
>> I don't know the internals to judge in which order items are associated 
>> in a map. It seems that normal association prepends; transient association 
>> appends; atom association does not obey any particular order.
>>
>> Anyway,* it seems to be a bug in that the transient didn't accept more 
>> than 8 items*. It should, I suppose.
>>
>> Or am I doing sth. very wrong?
>>
>> Thank you -
>>
>>
>>
>>
>>
>>
>>  -- 
>> -- 
>> 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/groups/opt_out.
>>  
>>  
>>
>
>

-- 
-- 
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/groups/opt_out.

Re: Released lein-cljsbuild 0.3.1

[David Nolen]

Thanks!

On Saturday, May 11, 2013, Evan Mezeske wrote:

> Nothing major in this release other than some bugfixes and bringing the
> default ClojureScript version up to date.  Thanks to all contributors!
>  Release notes:
>
> https://github.com/emezeske/lein-cljsbuild/blob/master/doc/RELEASE-NOTES.md
>
> -Evan
>
> --
> --
> 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 '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  '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  'clojure%2bunsubscr...@googlegroups.com');>.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
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/groups/opt_out.