require namespace implicitly
Mike Hinchey
Paul Stadig
Paul
--
You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
To post to this group, send email to cloju...@googlegroups.com.
To unsubscribe from this group, send email to clojure-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/clojure-dev?hl=en.
Stuart Halloway
* Do you want an extra if branch on every symbol in function position? If not, what are the rules, and how are they not confusing?
* Even not considering the performance, such a change would make code loading implicit and magical, with no lower level to escape to for anyone who didn't want it.
Stu
Dimitry Gashinsky
I do not understand why one need explicit naming on command line. But
this reads quite explicit to me.
java -jar clojure.jar -e "(use 'clojure.set) (union #{1} #{2})"
DiG
Paul Stadig
Why would there have to be any more of a performance hit? Catch the class not found exception and try to load code. The JVM I already doing the checking.
If you fully qualify a Java class name it loads code. It doesn't seem a great semantic or syntactic leap to do the same for clojure namespaces, which are classes.
Or am I being too simplistic?
Mike Hinchey
Paul Stadig
I mean I'm not saying you should rely on this all over your production app, but for repl usage I can see the benefit.
> .
>>> For more options, visit this group at
> http://groups.google.com/group/clojure-dev?hl=en.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
> "Clojure Dev" group.
>> To post to this group, send email to cloju...@googlegroups.com.
>> To unsubscribe from this group, send email to
Chouser
<stuart....@gmail.com> wrote:
> This scares me, both from a performance and semantics perspective:
>
> * Do you want an extra if branch on every symbol in function position? If not, what are the rules, and how are they not confusing?
I think this would actually have to happen at compile time, as with
all var name resolution. When the var is resolved by the compiler, it
would find no such namespace or class and attempt to 'require' it. If
that succeeds, try once more to resolve the var in that namespace --
if either that or the 'require' itself fails, give up. I'm not sure
if you'd have to do something different for AOT, like emit code to do
that same require in the namespace's init. In short, no runtime
performance implication at all.
> * Even not considering the performance, such a change would make code loading implicit and magical, with no lower level to escape to for anyone who didn't want it.
As others have mentioned, I think that ship already sailed. If I say
some.old.KlassName/FOO to refer to a static Java member, I can at that
moment trigger all kinds of class init side-effect depending on the
specific contents of my classpath, very much like as is being proposed
for namespaces.
--Chouser
http://joyofclojure.com/
Laurent PETIT
Chas Emerick
helpful: using clutch's view server for CouchDB, one needs to
(require ...) and then (resolve ...) in order to get around not
(currently) having a way to require a namespace before referring to
one of its definitions.
+1
Mike, is there a ticket for this in assembla?
- Chas
Mike Hinchey
Nicolas Buduroi
and also great idea for the repl.
Stuart Sierra
S
Chas Emerick
different than the implicit access and initialization of fully-named
Java classes, with (AFAICT) all perf considerations confined to
compile time?
- Chas
Steve Miner
I might call the proposed feature "auto-require". It could be a property of your namespace, something like the :refer-clojure reference option for the ns macro.
For example, to allow auto-require to work for any lib, except clojure.dangerous, you could write:
(ns foo.bar
(:auto-require :exclude [clojure.dangerous]))
If the programmer is concerned about too much magic, he can turn off the feature like:
(ns foo.bar
(:auto-require :include []))
In which case, no lib can be auto-required, and you would get today's behavior.
Personally, I would prefer that when no :auto-require reference is given, the effect would be: (:auto-require :exclude []). That is, implicit namespace recognition works for any lib. But if the new feature is not universally accepted, you could make the default be (:auto-require :include []).
In any case, I think it would definitely be a nice feature for the user namespace as it would make it easier to get started.
Steve Miner
Christophe Grand
--
You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
To post to this group, send email to cloju...@googlegroups.com.
To unsubscribe from this group, send email to clojure-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/clojure-dev?hl=en.
--
Professional: http://cgrand.net/ (fr)
On Clojure: http://clj-me.cgrand.net/ (en)
Phil Hagelberg
> +1 for me
The fact is it's quite easy to have a namespace A that relies on
another namespace B having being required without explicitly listing B
in A's ns form; you don't notice the fact that the explicit require is
missing because C requires B and you've always had C loaded before
loading A. I'm sure this has happened a lot already with clojure.set
since clojure.set has been required implicitly in the past. So it's
easy to have namespaces that only work by accident, and this proposal
makes that problem go away without introducing any new actual problems
beyond "it makes me feel nervous".
+1
-Phil
Laurent PETIT
That's what I already said some more posts above (though you explained it better), and for me too, it's a
+1
-Phil
Stephen C. Gilardi
Cosmin Stejerean
Shall we move this to a ticket and a patch?
- Cosmin
Mike Hinchey
-Mike