Lee,
On our work projects at Runa, we have an unwritten code standard of always
writing out the full namespace, and not using shortcuts as you suggest.
The reason being that it can be very hard to search for usages of a
namespace if you don't fully qualify them, which makes refactoring a
nightmare on projects with 250+ namespaces.
On Sat, Jul 27, 2013 at 4:00 PM, 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.
>
>
>
--
--
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.
