For this to even have a chance at making it into Clojure you need to
consider all the edge cases. So I have two questions
a) How do you plan on having this backwards-compatible with existing code?
You will have to support both the old and new versions on the same Clojure
compiler. Notice that this is completely valid in the current compiler:
(ns foo
[require [clojure.string :as c]])
b) You will also need a very concise, clear definition on why the new
approach is better. Once again, please notice that your "old school"
example could also have been written in a much more concise manner:
(ns one.fresh-server
(:refer-clojure :exclude [ancestors printf])
(:require [one.reload :as reload]
[one.middleware :as middleware]
[net.cgrand.enlive-html :as html]
[ring.adapter.jetty :refer (run-jetty)]
[ring.middleware.file :refer (wrap-file)]
[ring.middleware.file-info :refer (wrap-file-info)]
[ring.middleware.stacktrace :refer (wrap-stacktrace)]
[ring.util.response :refer (file-response)])
(:import (org.apache.maven.artifact.resolver ArtifactResolver)
(java.io File))))
As a support to the current method let me point out the following. We have
3 constructs in this case, each only does one thing:
a) refer-clojure - allows you to :exclude certain symbols from being
imported by default
b) require loads clojure namespaces
c) import loads Java classes
Your example also has the following problem:
bar=> (ns foo.bar)
nil
foo.bar=>
foo.bar=> (ns foo)
nil
foo=> (defprotocol bar (dostuff [this]))
bar
foo=> (ns user)
nil
user=> (ns user (:require [foo.bar]) (:import [foo.bar]))
nil
user=> bar
foo.bar
user=> (class bar)
java.lang.Class
With the current design we can clearly distinguish between loading a java
class, and loading a clojure namespace. In the example above, we need this
if we want to clearly load both the java interface foo.bar as well as the
clojure namespace foo.bar.
How would the new syntax express such a ns statement, and how would the
semantics be clearer in this approach?
Timothy Baldridge
On Tue, Aug 6, 2013 at 8:51 AM, Greg <g...@kinostudios.com> wrote:
> 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<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.
>
>
>
>
>
--
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)
--
--
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.
