Folks, I feel this thread has gotten derailed by the discussion of implicit imports.
This thread is not about that. It's not about asterisks, or :use, it's about a
simplified syntax for the 'ns' form.
PLEASE use the "Re: Can we please deprecate the :use directive ?" thread to
discuss whether implicit imports are a good idea or not. All of comments here
about implicitly interning symbols from a namespace are just as relevant to
this proposed syntax as they are to the currently existing one.
Once again, the (latest version) of the syntax being proposed is:
Old School:
(ns one.fresh-server
(:refer-clojure :exclude [ancestors printf])
(:use core.matrix
[ring.adapter.jetty :only (run-jetty)]
[ring.middleware.file :only (wrap-file)]
[ring.middleware.file-info :only (wrap-file-info)]
[ring.middleware.stacktrace :only (wrap-stacktrace)]
[ring.util.response :only (file-response)])
(:require [one.reload :as reload]
[one.middleware :as middleware]
[net.cgrand.enlive-html :as html])
(:import (org.apache.maven.artifact.resolver ArtifactResolver)
(java.io File))))
New School:
(ns two.namespace
[clojure [core :except (ancestors printf)]]
[core [matrix math bs]] ; same as (:use (core matrix math bs))
[[some-ns]] ; same as (:use some-ns)
[ring.adapter.jetty (run-jetty :as jetty)]
[ring.middleware.file ("warp-*")] ; refers all functions beginning with
"wrap-"
; regex not supported because too confusing
[ring.middleware.file-info (wrap-file-info)]
[ring.middleware.stacktrace (wrap-stacktrace)]
[ring.util.response (file-response)]
[one reload middleware]
[net.cgrand enlive-html :as html]
[org.apache.maven.artifact.resolver ArtifactResolver]
[java.io File InputStream])
Four key rules to the new syntax:
1) vectors can only contain namespaces and the keywords :as and :except
2) vectors within vectors will refer everything in the the namespaces specified
in them
3) lists can only contain functions and the keyword :as to rename functions.
4) namespaces are referred by placing a space after the namespace prefix
Also, an added feature/rule is that globbing-based strings can be used to save
on typing (as shown in the example above).
- Greg
--
Please do not email me anything that you are not comfortable also sharing with
the NSA.
On Aug 6, 2013, at 7:55 AM, Curtis Summers <curtis.summ...@gmail.com> wrote:
> I agree that wildcards make it "easy" (in the nearness sense), but from a
> long-term maintainability standpoint, I'd prefer to have explicit imports as
> is. When I'm reading your code a year from now and need to look-up the docs
> on a class, wildcards make me (and anyone else in the future) have to do that
> look-up every time. It's almost the same argument as to why (:use) is a bad
> idea--you're dumping a bunch of symbols into your namespace. So, you're
> trading some upfront ease for some long-term simplicity.
>
> Yes, lots of Java tutorials are of no help in this endeavor :( (Again, see
> the parallel in the Clojure world with so much "getting started/example" code
> showing :use instead of :require).
>
> -Curtis
>
>
> The argument for wildcards is very simple. Go to just about any Java
> tutorial, for example:
> http://docs.oracle.com/javase/tutorial/displayCode.html?code=http://docs.oracle.com/javase/tutorial/2d/images/examples/LoadImageApp.java
>
> The sample code starts off with a dozen wildcard imports. If I want to try
> to use these techniques in Clojure, I have absolutely no idea which specific
> classes to require. This creates a tremendous obstacle to consuming Java
> libraries. This has affected me personally on several occasions, preventing
> me from successfully figuring out how to use some Java library from Clojure.
>
> Maybe it's not ideal if Clojure has to walk the classpath, but the
> alternative is that I have to manually walk the classpath and jars myself
> with no idea what I'm looking for. Surely it's better for this to be handled
> through an automated process.
>
> --
> --
> 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
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
signature.asc
Description: Message signed with OpenPGP using GPGMail
