New ns function

[rob....@gmail.com]

I've been playing with the new (ns) method and I like it. When I read
the docs I found that I wasn't using it correctly, although my usage
seems to work just fine and be a little nicer ( where I define nicer
by the number of characters I type ).

The docs suggest this usage:

(ns foo
(:use (my.lib this that)))

And I found that I had used it as:

(ns foo
(use lib1 lib2))

The difference is only a colon, but hey, a colon is two keystrokes. Is
this an alternative accepted usage style, or have I simply stumbled
upon a pattern that works by coincidence rather than intent; behavior
that might disappear at some point in the future.


Thanks,


Rob Lally.

[Rich Hickey]

On Aug 30, 10:53 am, "rob.la...@gmail.com" <rob.la...@gmail.com>
wrote:

Yup, coincidence, please use as documented. Tools, for instance, might
analyze ns forms looking for :use etc and not find them.

Rich

[Stephen C. Gilardi]

On Aug 30, 2008, at 11:23 AM, Rich Hickey wrote:

Yup, coincidence, please use as documented. Tools, for instance, might analyze ns forms looking for :use etc and not find them.

I suggest adding (:load-resources ...) as a supported reference argument for 'ns.

--Steve

[Rich Hickey]

I wonder. It seems in many cases the loaded resources will need
definitions made by the parent/loadee, in which case you'd want to
load them at the end of the file.

Rich

[Stephen C. Gilardi]

On Sep 2, 2008, at 7:32 PM, Rich Hickey wrote:

I suggest adding (:load-resources ...) as a supported reference

argument for 'ns.

I wonder. It seems in many cases the loaded resources will need
definitions made by the parent/loadee, in which case you'd want to
load them at the end of the file.

That's certainly one way to do it. I was thinking that once a lib grows enough to warrant separating it into  multiple resources, a clean way to tie the whole lib together would be for the root resource to prepare the namespace, load other resources in the right order, and not do much else.

Even in the case of a lib big enough to be broken into multiple subdirectories, it still makes sense for the root resource to load all the other resources directly. The only relative paths available are namespace-relative--the kind of paths that are natural to use in the root resource and less so elsewhere.

The upside of allowing (:load-resources ...) is that under one reasonable structuring of things, a tool could determine all the namespaces, classes, and (code) resources associated with a lib by parsing a single "ns" call.

--Steve