On Wed, Nov 11, 2009 at 3:54 PM, Laurent PETIT <laurent.pe...@gmail.com>wrote:
> 2009/11/11 Andrew Boekhoff <boekho...@gmail.com>:
> >> > (:uses [clojure.core :exclude [read])
> >> > [clojure.contrib.graph]
> >> > [clojure.contrib.fcase]
> >> > [clojure.contrib.stream-utils :as su]
> >> > [clojure.contrib.def :refer-all true]
> >> > [clojure.contrib.except :refer-all true]
> >> > [clojure.contrib.server-socket :refer-all true]
> >> > [clojure.contrib.lazy-xml :refer-all true]
> >> > [clojure.contrib.java-utils :only [as-str]]
> >> > [clojure.stacktrace :only [root-cause]]
> >> > [clojure.walk :only [postwalk]])
> >
> > +1
> >
> > As a thought (which may offend some fans of explicit delimiters),
> > dropping the brackets and delimiting on symbols could be an option.
> >
> > (ns foo
> > (uses clojure.contrib.graph
> > clojure.contrib.stream-utils :as su
> > clojure.contrib.java-utils :only [as-str]))
>
> +1 on giving up on the extra vectors, since they give nothing more if
> the dsl becomes that simple (and I also like it becomes that simple
> !).
>
> One question, to be sure to correctly understand: only one optional
> option is allowed after the symbol of a namespace ? (that is possible
> options are considered mutually exclusive ?)
Not necessarily; if the parsing rule is that a keyword makes a following
symbol part of an option, rather than a namespace name, and all options
apply to the most recently seen namespace name. So
(ns foo
(uses clojure.contrib.duck-streams :as ds :only [reader-on spit]
clojure.contrib.seq-utils :as su))
would alias everything in seq-utils under su, e.g. su/includes?, and would
also produce ds/reader-on and ds/spit.
Other combinations might be allowed too. For example, perhaps
(ns foo
(uses clojure.contrib.duck-streams :only [reader-on spit] :as ds ))
should produce bindings for reader-on and spit in foo and for everything as
ds/whatever, and even
(ns foo
(uses clojure.contrib.duck-streams
:only [reader-on spit]
:as ds :only [writer-on]))
would get you reader-on, spit, and ds/writer-on.
One question: how would Java class imports be dealt with? I think it should
be unified:
(ns foo
(uses java.io :only [File FileInputStream] :as io))
gets you File, FileInputStream, io/FileOutputStream,
io/FileNotFoundException, etc.
The one difference being that :refer-all can't work easily for Java
packages, since there's no easy way that I'm aware of to programmatically
get a global list of everything in a Java package, although I suppose any
bare symbol not otherwise resolved could be searched for in each Java
package in turn that was refer-all'd. Detecting and forcing resolution of
name conflicts wouldn't work in this case, though, which bothers me; either
conflicts involving two Java classes brought in via refer-all would not be
detected at all, or they'd be detected only at the point where the name
resolution happens, thus possibly not until run-time, and then they would
depend on what jars might be on that particular install's classpath. Ouch.
So, I vote for not allowing :refer-all for Java packages.
As for how it can distinguish Java classes from functions:
First, in the case above the java.io package has no loadable Clojure
namespace in it, so obviously any name being used from it should be assumed
to be a Java class. Now if we use foo.bar and there's both a foo/bar.clj
with a (defn my-fn ...) and a foo/bar/Baz.class on the classpath, and we
have (uses foo.bar :only [my-fn Baz]), it should find my-fn in the Clojure
namespace, fail to find any Baz var in the Clojure namespace, and then see
if there's a Baz class in a Java package foo.bar, and so end up bringing in
the my-fn Clojure function and the Baz class as one would expect.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
