2009/3/5 Jonathan Tran
>
> On Mar 5, 9:24 am, Chouser wrote:
>
> > So the least-breaking change proposed here would be simply that if
> > :use is given an :as parameter, that it no longer also refer all the
> > other symbols directly.
> >
> > Rich seemed to want to reduce the breakage here as mu
On Mar 5, 10:50 am, Jonathan Tran wrote:
> No!!! Please, not _another_ namespace function. I find all the
> namespace stuff in Clojure to be overly complicated already. To
> newcomers, it must be utterly confusing... with ns, use, import,
> require, refer, and then all the ns-* and *-ns stuff.
On Mar 5, 9:24 am, Chouser wrote:
> So the least-breaking change proposed here would be simply that if
> :use is given an :as parameter, that it no longer also refer all the
> other symbols directly.
>
> Rich seemed to want to reduce the breakage here as much as possible,
> and IMHO this is pret
On Thu, Mar 5, 2009 at 9:00 AM, Stephen C. Gilardi wrote:
>
> On Mar 5, 2009, at 8:50 AM, Chouser wrote:
>
>> Aren't there already no-arg options like :reload and :verbose?
>
> Those apply to the entire :use or :require clause. They are flags that are
> peers with libspecs, not within them.
Fair
On Mar 5, 2009, at 8:50 AM, Chouser wrote:
Aren't there already no-arg options like :reload and :verbose?
Those apply to the entire :use or :require clause. They are flags that
are peers with libspecs, not within them.
--Steve
smime.p7s
Description: S/MIME cryptographic signature
On Thu, Mar 5, 2009 at 12:00 AM, Stephen C. Gilardi wrote:
>
> On Mar 4, 2009, at 11:46 PM, Chouser wrote:
>
>> Adding an :all option as Steve suggests would clean this up even more:
>>
>> (ns util
>> (:use [really.long.namespace.util :as util :all]))
>
> I looked into this further after sugge
Thanks, Steve and Chouser!
> Well, there's been two proposals. In my original less radical one,
> I already addressed this requirement. For your example:
>
> (ns util
>(:use [really.long.namespace.util :as util :exclude ()]))
>
That would be perfectly fine with me.
I just wanted to menti
On Mar 4, 2009, at 11:46 PM, Chouser wrote:
Adding an :all option as Steve suggests would clean this up even more:
(ns util
(:use [really.long.namespace.util :as util :all]))
I looked into this further after suggesting it and was reminded that
it would be difficult to support an option
On Wed, Mar 4, 2009 at 10:10 PM, Jason Wolfe wrote:
>
> I have a file really/long/namespace/util.clj with a bunch of
> utilities, structs, and method definitions. Following (what I gather
> is) an accepted convention, these structs have a :class key that maps
> to a namespace-qualified keyword.
> Intentionally referring an entire namespace in and also aliasing it
> seems a very odd thing to do. The number of libs this change would
> break is very likely to be tiny and the breakage will be obvious and
> easy to fix.
I just ran into an instance where I might want to do just this.
I have
On Feb 23, 2009, at 1:54 PM, Chouser wrote:
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 a
On Feb 23, 2:59 pm, Chouser wrote:
> On Mon, Feb 23, 2009 at 2:33 PM, Stephen C. Gilardi wrote:
> > 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 impl
On Mon, Feb 23, 2009 at 3:52 PM, Perry Trolard wrote:
>
> +1 from me, too.
>
> As to an :all shortcut that's synonymous with :exclude (), I think
> convenience at the REPL is a good argument for :all. (I'm assuming
> that the `require` macro would disappear, too.)
>
> For Cosmin's thought (:as mu
+1 from me, too.
As to an :all shortcut that's synonymous with :exclude (), I think
convenience at the REPL is a good argument for :all. (I'm assuming
that the `require` macro would disappear, too.)
For Cosmin's thought (:as mutually exclusive with :exclude, :only,
& :rename), it does seem to me
On Mon, Feb 23, 2009 at 2:29 PM, James Reeves wrote:
>
> On Feb 23, 6:54 pm, Chouser wrote:
> > (ns n01se.net.graph.issues
> > (:import (java.text SimpleDateFormat ParsePosition)
> >(java.util GregorianCalendar Calendar)
> >(org.jfree.chart ChartFrame))
> > (:use [cloj
On Feb 23, 6:54 pm, Chouser wrote:
> (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
Stuart is gonna love you guys ;)
On Feb 23, 2:59 pm, Chouser wrote:
> On Mon, Feb 23, 2009 at 2:33 PM, Stephen C. Gilardi wrote:
>
>
>
>
>
> > 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
>
On Mon, Feb 23, 2009 at 2:33 PM, Stephen C. Gilardi wrote:
>
> 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
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 ChartFra
I have a feature request for the 'use' function. First an example. I
have some real-world code like this:
(ns n01se.net.graph.issues
(:import (java.text SimpleDateFormat ParsePosition)
(java.util GregorianCalendar Calendar)
(org.jfree.chart ChartFrame))
(:use [clojure.
20 matches
Mail list logo
