On Feb 23, 2009, at 1:54 PM, Chouser wrote:
After kicking around some alternatives, I realized 'use' is sufficient
for all cases:
(ns n01se.net.graph.issues
(:import (java.text SimpleDateFormat ParsePosition)
(java.util GregorianCalendar Calendar)
(org.jfree.chart ChartFrame))
(:use [clojure.zip :only (xml-zip node)]
[clojure.contrib.zip-filter :as zf :only ()]
[clojure.contrib.zip-filter.xml :only (xml-> attr text)]
[clojure.contrib.lazy-xml :only (parse-trim)]
[clojure.contrib.seq-utils :only (reductions)]
[com.markmfredrickson.dejcartes :as chart :only ()]))
This is much prettier to my eye, but has a couple things that could be
better. So, feature request #1 is that if a libspec has an ":as"
option, that the ":only []" option be implied. That is, if I'm
aliasing an namespace, don't by default refer in all that namespaces
vars.
While this would technically be a breaking change, it seems unlikely
to me that it will cause much if any real-world disruption. Any usage
that actually intended to both alias the namespace and refer all the
symbols could say [my.lib :as mylib :exclude ()]
I like this a lot.At that point, it seems only a small step to remove "require" entirely which I think would be a long-term plus--coalescing two very similar things (require and use) into one (use) with (possibly) an additional option.
In order to keep it clear what non-core symbols refer to, several of us have been recommending always using either :as or :only and only very rarely if ever a "naked" use.
How about this as an alternative in the same spirit as your proposal:- change the name of :require to :use -- :use with no options changes from an implicit "refer all" to an implicit "refer none"
- :as, :only, :exclude, and :rename work as they do now
- add an :all option to cover the case of really wanting to refer in
all of the subject namespace. It would have the same effect as
":exclude ()". (Alternatively, perhaps we intend for this to be a rare
enough use case that ":exclude ()" by itself would suffice.)
Of course this would be a bigger, definitely breaking change, but not breakage that will be at all difficult to find or fix in old or new code.
--Steve
smime.p7s
Description: S/MIME cryptographic signature
