import blah.*

[Dustin Withers]

Does Clojure have away to import all of a namespace? Is that what
refer does? Does someone have an example they can show me?

Thanks,
-dustin

[Stephen C. Gilardi]

On Jun 14, 2008, at 9:40 PM, Dustin Withers wrote:

> Does Clojure have away to import all of a namespace? Is that what
> refer does? Does someone have an example they can show me?

Clojure namespaces are distinct from Java packages. The import
command brings specified names from a Java package into the current
namespace. I'm not aware of a way to wildcard the names that are
imported.

The refer command brings names from another Clojure namspace into the
current Clojure namespace.

user=> (doc import)
-------------------------
clojure/import
([& import-lists])
import-list => (package-symbol class-name-symbols*)

For each name in class-name-symbols, adds a mapping from name to the
class named by package.name to the current namespace.
nil
user=> (doc refer)
-------------------------
clojure/refer
([ns-sym & filters])
refers to all public vars of ns, subject to filters.
filters can include at most one each of:

:exclude list-of-symbols
:only list-of-symbols
:rename map-of-fromsymbol-tosymbol

For each public interned var in the namespace named by the symbol,
adds a mapping from the name of the var to the var to the current
namespace. Throws an exception if name is already mapped to
something else in the current namespace. Filters can be used to
select a subset, via inclusion or exclusion, or to provide a mapping
to a symbol different from the var's name, in order to prevent
clashes.
nil
user=>

This contains a simple example of each:

http://clojure-contrib.svn.sourceforge.net/viewvc/clojure-contrib/trunk/sql.clj?revision=33&view=markup

--Steve

[Dustin Withers]

Ok that makes sense. Is there by chance some kind of thing in Java
that will allow me some kind of introspection into packages so that I
can see what symbols they contain?

Thanks,
-dustin

> http://clojure-contrib.svn.sourceforge.net/viewvc/clojure-contrib/tru...
>
> --Steve

[Bry Ashman]

Easiest way would be to look in the jdk api javadoc when looking for
which classes are in which package.

Which can be found here (JDK 6):
http://java.sun.com/javase/6/docs/api/

The programmers guide can also be a good place to look for things it
is a superset of the api doc.

http://java.sun.com/javase/6/docs/

Regards,
Bry

[Zak Wilson]

I'm guessing what Dustin wants to do is write a function that will
look inside a package to get a list of classes, then map import over
it. Getting such a list by fetching the documentation over HTTP and
parsing the resulting HTML would certainly be an interesting way to
accomplish that. I think it would be good if Clojure had the ability
to import all classes in a package built in, or if it does, I would
like to see it better documented.

[Bry Ashman]

Ah, good point. I read it as just wanting a way to find out what a
package contains.

There doesn't appear to be anything in java.lang.reflect for
enumerating classes in a package directly. Seems to mainly for
traversing class hierarchies.

This thread ( http://forum.java.sun.com/thread.jspa?threadID=341935&start=0
) seems to suggest parsing the contents of the jar files.

I am not sure if importing all the classes from a package is a good
idea. Convenient maybe, but not a wise idea. Especially since our
import syntax is so much better than plain java.

Also because I am of the opinion that java interop does not belong
outside of libraries, and that we should be VERY wary about where the
java objects are, because of concurrency semantics ( I am stating this
blindly but I think it is right, please correct me otherwise ). I
don't think we should be using import that much.

Though we most likely will be for the near term until we start getting
native wrappers for all this common stuff. At which point our api
wrappers should be a lot better than the java api ;)

[Rich Hickey]

On Jun 15, 7:55 am, "Bry Ashman" <bryash...@gmail.com> wrote:
> Ah, good point. I read it as just wanting a way to find out what a
> package contains.
>
> There doesn't appear to be anything in java.lang.reflect for
> enumerating classes in a package directly. Seems to mainly for
> traversing class hierarchies.
>

> This thread (http://forum.java.sun.com/thread.jspa?threadID=341935&start=0

> ) seems to suggest parsing the contents of the jar files.
>
> I am not sure if importing all the classes from a package is a good
> idea. Convenient maybe, but not a wise idea. Especially since our
> import syntax is so much better than plain java.
>

Java packages are not enumerable. The only way to do so is to walk the
classpath/jars etc. I don't think import * is a good idea, as it
brings more into a namespace than you are going to use, making
Clojure's namespace enumeration, e.g. ns-imports, that much less
useful.

Rich

[vemv]

While coarse-grained imports are pretty obviously a suboptimal practice, I believe the lack of some this possibility (in at least some form) hinders exploratory programming / API discoverability.

Would it be feasible to add an :as directive to 'import? An use case:

; --- state of the editor at time T1 ----

(import '[java.util.concurrent] :as conc)

conc/ ; a completion popup appears. user presses DOWN, DOWN, TAB

; --- state of the editor at time T2 ----

(import '[java.util.concurrent DelayedQueue] :as conc) ; the symbol gets added to the import list.

conc/DelayedQueue ; the user can optionally drop the 'conc/' qualification by calling 'import again

There are are least two JVM langs (Java and Scala) that can perform package-wide imports. Don't know if they achieve this by walking the classpath as Rich indicates (which would mean - we can have this too!) or by leveraging a feature that is consequence of their less-dynamic nature.

[Herwig Hochleitner]

I'm not convinced about allowing wildcard imports. Same reason that we discourage use without :only for.

About discoverability: I'd take a look at the autocompletion code for swank-clojure, lein repl, et. al.

Maybe there is a contrib in there?

About your static/dynamic remark: In static langs there is a clear distinction between the compile class path and runtime class path. That way, you can't introduce new names by running with an upgraded library. So while wildcard imports are still suboptimal, they are not as volatile as in most dynamic langs. You can protect against that in clojure too by AOT compiling.

That said, package imports with :as clauses, as in your example, wouldn't even pose this problem. 

With (import '[com.package :as pkg]), Symbols using the pkg namespace alias could be resolved to their classes without walking the classpath.

That feature might actually be quite nice. I like how one can do that in clojurescript.

kind regards

[vemv]

Thanks for the answer Herwig!

swank-clojure and nrepl(.el) can do pretty amazing things. But in my opinion, at least in the context of Java interop there is still work left to do...

Lastly, as of today, what can clojurescript do that clojure can't?