On Jul 23, 2013, at 3:06 PM, Gary Trakhman wrote: > Yea, I have a single namespace with project-specific common utilities which I > refer to as u/some-util-function. For me, it's a bit scary to have implicit > symbols in scope. A typo can make a local binding refer to something that > might not exist in production, or at least not what's intended. Conversely, I > don't want extra code in my project that has nothing to do with the project. > Seems useful to enforce a separation of the artifact from the tools that made > it, more-so for a lib that other things depend on than a production app. > > The 'user' namespace can cover the use-case of convenience functions? > > Or, you can add those symbols dynamically at run-time when you need to with > something like: > https://github.com/flatland/useful/blob/develop/src/flatland/useful/ns.clj#L26 > > or some aggregated (require ..) calls. >
I'm sure I'm coming from a minority perspective on this, but for the kind of work I do it's often more important to be able to quickly sketch out and test ideas, without any ceremony about which functions come from where, than it is to ensure safety in a "production" environment which is really just me running it right now. In fact I'd sometimes like to go the other way and use everything in a whole directory subtree, or even to get rid of "using" altogether and have the runtime system find the function wherever it can (within reason :-) and let me know if it can't or if there's a conflict. I do understand that there are a great many programming contexts in which it would be foolish and dangerous to manage references so loosely and implicitly and dynamically. In fact it's a bad idea in some of my work too, so I'm slightly more disciplined than this some of the time. But my point is just that different users will have different priorities, and from where I sit, at least, it'd be nice to keep :use. -Lee -- -- 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.
