Wildcards for java imports will probably never be resolvable when the ns is called. By that I mean that java class loaders are not enumerable, so you cannot get this to work generally. This is a technical detail which objectively prevents the possibility to import "massively" class symbols into a namespace.
But as you said, languages such as java, etc. manage around this restriction. I'm no expert in this area, but my guess is that it's later during the compilation, when an unknown type is used for the first time, that the packages declared with wildcards are queried, and a that time with a specific type name to search for. What this means for clojure is that it's the compiler that would need to be changed. When faced with an unknown symbol, after having unsuccessfully resolved it by the usual ways, it would then query the class loader using as package prefix the wildcard-imported packages, in turn. And then report if nothing was found (error), more than one matching package was found (ambiguity), or just compile if one and only one package was found. This would still follow the principle of : pay only for what you need, since for namespaces not declaring any wildcard-package, there would be no unnecessary findClass calls to the class loader. I'm speaking here because I can see value in what Mark and Lee are suggesting. Indeed, when doing what we all love in the Repl, that is rapid development, we can live with the costs of some extra packages / ns lookups. And it would still be possible, when time comes to "freeze" a namespace, to call some helper method to help get an un-wildcardized ns declaration. My 0,02€, Laurent Le lundi 5 août 2013, Tassilo Horn a écrit : > Mark Engelberg <mark.engelb...@gmail.com <javascript:;>> writes: > > >> I think it's java that is at fault here. I think wildcards should > >> never have been part of java to begin with. The argument here is > >> basically exactly the same as why :use shouldn't be used, so I wont > >> explain it further. > > > > Well, Clojure is hosted on Java and clean interop is one of its goals. > > > > The fact of the matter is that many Java libraries are designed and > > documented with the existence of the wildcard in mind. The code is > > fragmented across many small classes that are designed to be imported > > en masse with a wildcard. > > The good thing in Java land is that IDEs like Eclipse automatically > replace "import foo.*;" with a list of imports that are actually used in > the compilation unit. > > Bye, > Tassilo > > -- > -- > 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<javascript:;> > 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 <javascript:;> > 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 <javascript:;>. > 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.
