I haven't tried this, so apologies if it couldn't even work, but have you considered providing a fn in your library intended to be used inside the ns macro? The refer-clojure :exclude boilerplate could be replaced with something like this.
(ns my-thing (:require core.matrix.ns) (:core.matrix.ns/exclude-clojure-core-math-ops) (:use core.matrix)) It's not too much boilerplate, and probably explicit enough for anyone who was going to :refer :all anyway. (Sorry for butchering your lib's name. Mobile keyboard bad for code.) On Sep 4, 2013 8: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. > -- -- 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.
