I think what we're proposing is not about removing the capability to do 'use'. That will remain, it's clojure after all. You could also implement it yourself easily enough. The issue is whether it's worthwhile to have it as a core function, without some kind of notice that better things exist.
For instance, we have defrecords now, no one's going to reach for defstruct because records are documented and promoted more thoroughly. But 'use' is more pervasive, and also 'easier'. As the language grows, it'll be good for newcomers to have less things to think about, so deprecation is a way to counter bad inertia. The damage of 'use' is also less visible on the small scale, so that's why it's hard to make an argument about it. :require is proportionately more verbose for an effect. Use's verbosity is inversely proportional to its effect, so it takes extra effort to limit its effects. A limited scope by default is what I mean by 'good', for similar reasons that clojure goes with 'immutability by default'. On Tue, Jul 23, 2013 at 3:57 PM, Lee Spector <lspec...@hampshire.edu> wrote: > > 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. > > > -- -- 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.
