BTW Lee, going back to your original question, I think the solution that
you came up with is the only one I can think of that does what you want. Of
course you can put it on one line:
(ns use2require.core
(:require [use2require [myfns :refer :all] [yourfns :refer :all]]))
But I agree it's more verbose. Still, the idea of moving to :require is
that you're more explicit about what you're doing, so maybe that's a good
thing. Personally I prefer my require clauses explicitly listed so I have
some pretty huge ns
declarations, but it doesn't bother me - I hardly ever actually look at
them, and when I do I can immediately see what's going on.
On 28 July 2013 11:00, Colin Fleming <colin.mailingl...@gmail.com> wrote:
> I think there's a lot of scope for automatic namespace management. I'm
> already doing this for Java but it's more complicated for Clojure.
> Currently for Java I automatically add an import via a popup if the user
> has a class short name (e.g. "ArrayList") that isn't imported, and I also
> allow automatic importing of fully qualified names. This also works during
> completion (i.e. if the user autocompletes the short name of a class it
> will auto-import it). This also all works in the REPL editor - I
> automatically execute an (import 'class) statement in those cases.
>
> For Clojure it's a little trickier. I'm planning something similar to the
> above for Clojure symbols but how to specify the namespace alias is
> difficult from a UI point of view. If I type str/tr and then autocomplete
> I'd like a suggestion to ":require [clojure.string :as str]" and then
> autocomplete str/trim. But if I just type tr I'm not sure what should
> happen - currently I'm thinking of offering ":require [clojure.string
> :refer [trim]]", ":require [clojure.string :as str]" as options, where in
> the second one the prefix is either the most-frequently used alias for that
> NS in the project or the last segment of the namespace ("string" in this
> case) if not found. But I'm not sure how well this will work, you could
> potentially get a lot of completions, I'll probably make it so that the
> user has to explicitly request these completions (pressing complete twice,
> or something similar).
>
> I think adding intention actions to automatically refactor :use
> declarations into the corresponding :require should be pretty
> straightforward, though. I think all these features are a huge win for
> productivity, the automatic class import has been a life saver for me
> (since the plugin is a big interop project).
>
>
> On 28 July 2013 07:49, Laurent PETIT <laurent.pe...@gmail.com> wrote:
>
>> 2013/7/27 Lee Spector <lspec...@hampshire.edu>:
>> >
>> > On Jul 27, 2013, at 1:25 PM, Laurent PETIT wrote:
>> >>>
>> >>> But it's really not much better. This too will explode the number of
>> lines in many of my ns declarations.
>> >>>
>> >>> Is there indeed a reasonably concise way to do this? What is it?
>> >>
>> >> Would it still bother you if the IDE helped maintain the ns
>> declaration?
>> >
>> > I guess it depends on the details.
>> >
>> > If I can completely ignore the ns declaration and tell the IDE, through
>> a menu selection or key command, something like "Make an ns declaration
>> that includes what I need, based on what I call here and where those things
>> can be found in the project directory and other reasonable places," and I
>> really never have to pay attention to the big mess that it produces for
>> that, then that would indeed be quite excellent. Better than what I have to
>> do now.
>>
>> Here's how I see it: it would change the ns declaration depending on
>> the choices you make in the code completion list. That is, the code
>> completion list would have to not only be made of what's already
>> loaded in the REPL (as is generally the case), but also with all
>> possible symbols from libraries currently accessible directly or
>> transitively, depending on the project's classpath.
>> I even sometimes dream of indexing via lucene all the open source
>> libraries available via github, and have the created Index be the base
>> for code completion. This would probably be awesome. After all, in a
>> project, it's generally the project's source code which changes and
>> needs dynamic treatment. The dependencies are generally known in
>> advance, computable, and stable.
>>
>>
>> > But if my actual ns declarations have to get a lot bigger than they are
>> now -- that is, if there isn't a reasonably concise way to use :require
>> :refer :all in place of :use -- then I would really be dependent on such an
>> IDE feature. And if the IDE "helps" but I still have to pay attention to
>> the details then that may still be worse than the current situation.
>> >
>> > Seems better to me to leave :use alone and/or to ensure that there's a
>> reasonably concise way to get the same effect from :require :refer :all.
>> Maybe there is -- nobody has chimed in with it yet but I only posted the
>> query this morning.
>> >
>> > Of course I'd still really like implicit "use what you need and don't
>> bother me about it unless you need to" -- but I am not holding my breath
>> for this :-).
>> >
>> > -Lee
>> >
>> >
>> > --
>> > --
>> > 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.
>>
>>
>>
>
--
--
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.
