You only get the warning if you 'use' the namespace or 'refer all' tho', correct?
And we've recently seen a lot of discussion that basically says "don't do that" so it seems that either users of core.matric are going to have two "approved" choices: * require core.matrix with an alias, or choose to rename colliding names however you want * exclude the colliding symbols via refer-clojure and require them from core.matrix as referred symbols That's seems right to me: it is explicit and provides no surprises; it gives the user control over how to manage things. Sean On Wed, Sep 4, 2013 at 6:22 PM, Mikera <mike.r.anderson...@gmail.com> wrote: > Hi all, > > While building the API for core.matrix, I've fun into a few cases where the > "best" name is a direct clash with clojure.core. > > Examples are "+", "zero?", "vector?", "==" > > In many of these cases, the core.matrix behaviour is a natural extension of > the clojure.core function (i.e. it extends the same functionality to > arbitrary N-dimensional arrays). > > I'm not very happy with any of the options I can see for handling this: > > A) Use the good names in the "clojure.core.matrix" namespace. Problem: that > gives you a ton of nasty warnings of the type "WARNING: + already refers to: > #'clojure.core/+ in namespace: test.blank, being replaced by: > #'clojure.core.matrix/+". Significant boilerplate must be maintained by the > user in their ns declaration to prevent these warnings. I don't like forcing > users to maintain boilerplate, and I think that normal idiomatic usage > should be warning-free. > > B) Separate the name-clashing functions into separate namespaces - e.g. > "clojure.core.matrix.operators". Problem: that's something of an artificial > division, and again it forces users to do extra ns-management work to access > the functions they want. > > C) Use different names. Problem: names would be worse, and this would be > inconsistent and confusing, especially for functions that do effectively the > same thing. > > D) Encourage users to use aliases. Problem: that's horrendously ugly and > inconvenient for numerical code. Users with any sense of elegance in their > coding style would quite rightly throw their hands up in disgust. > > Currently we're doing B), I'd prefer to do A) but can't figure out a way to > automatically suppress the warnings. > > Any better ideas? > > > > -- > -- > 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.
