I gave some thought to the Integer vs. Int32 issue.

I think what would help here is a way to alias classes when :importing them.

It would require tweaking the ns macro and possibly parts of the
runtime. The outcome would be to allow something like

(ns foo
  (:import (java.util.concurrent
             AtomicBoolean (ConcurrentHashMap :as CHM) AtomicInteger)))

(defn make-default-chm []
  (CHM. 12 12 12))

...

Handy so far for abbreviating some longer classnames, and the
application to CLR portability is apparent:

(ns foo
  (:import (System (Int32 :as Integer))))

In theory, you'd just add this import to make code full of ^Integer
hints compile under ClojureCLR. You'd still need two versions of the
source file though, a CLR version with the import and a JVM version
without.

But then why not go even further and have the ns macro able to tell
what platform it's on?

(ns foo
  (:import-jvm (package1.package2 BarBaz as BBaz))
  (:import-clr (Package3.Package4.BooBaz as BBaz)))

(code-using-BBaz...)

Now in theory the one source file works under both.

Of course this doesn't help you if the BarBaz and BooBaz classes have
sufficiently different behavior that they can't be drop-in
replacements for each other. In that case the ideal would be to have
Clojure wrappers for the classes that translated into their semantics
from some common API -- an abstraction layer with separate JVM and CLR
versions (and normal imports). Now the problem becomes selecting
between these, but if the ns macro is going to learn to tell if it's
running on a JVM or the CLR anyway, why not add, also, :use-jvm,
:use-clr, :require-jvm, and :require-clr? Now the appropriate
abstraction layer can be used depending on the underlying runtime
without having to maintain two separate source trees mostly containing
copies of the same files but for a few platform-specific ones. Instead
there will be two differently-named versions of each platform-specific
file and one of everything else in a single source tree, and in some
cases fewer platform-specific files (e.g. where Int32 vs. Integer had
formerly required there be two versions of a file but :import-foo
allows there to be just one).

-- 
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

Reply via email to