I vote for adding :as to import. I've personally thought of other situations where this could be useful.
Being able to alias a (Java) package might be useful too: (import '((java.util.concurrent :as juc) LinkedBlockingQueue ReadWriteLock)) (def my-queue (juc/LinkedBlockingQueue.)) Most useful with conflicting class names, e.g. java.util.Date and javax.sql.Date: UDate vs. SDate u/Date vs. s/Date etc. On Fri, Nov 1, 2013 at 4:40 PM, Mark <mjt0...@gmail.com> wrote: > At work, we're primarily a Scala shop, but I've been writing some small > Clojure utilities to handle quick tasks here and there (stuff I'd written > in Python previously). I was hoping to make use of some of the Scala > libraries we'd already written, but I ran into an Java/Scala interop > problem that I couldn't solve cleanly. > > The problem is with Scala's package objects. If you're not familiar with > them, it's how Scala organizes top-level functions (ie, functions that do > not belong to an object or class). It looks like Scala compiles package > objects down to an object called "package". They are lexically > distinguished from one another by the packages to which they belong. > > At the REPL, I was able to import one and call a method from it by doing: > > > (import '(org.fooinstitute.team.libary.foo package)) > => org.fooinstitute.team.library.foo.package > > (package/isFoo "foo") > => true > > However, if I needed to use code from multiple Scala package objects, I > couldn't import them all individually, because there would be a name > conflict, and the last one imported would presumably shadow all the others. > > Alternatively, I could use the fully-qualified name for the package > objects, like so: > > > (org.fooinstitute.team.library.foo.package/isFoo "foo") > => true > > But that's kind of verbose. The only other solution I can think of is to > write thin wrappers around the package objects I'd like to use, but as I > understand it, the general Clojure philosophy eschews that practice, since > Java interop should be fairly seamless (and is in just about every other > case I've encountered so far). > > I think my preferred solution would be to allow imported Java classes to > be aliased, so I could do this: > > > (import '(org.fooinstitute.team.library.foo package :as foop)) > => org.fooinstitute.team.library.foo.package > > (foop/isFoo "foop") > => false > > But to the best of my knowledge (and searching), that doesn't exist in > Clojure. > > Has anyone encountered this and found a satisfying solution? > > Thanks, > Mark > > -- > -- > 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. > -- -- 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.
