It's true that both Laurent's and my suggestions are complicated, but we're thinking about it from an implementer's point of view. What I currently have from a *user's* point of view for classes is great, you just don't think about it. I don't know how much Java development you've done, but this is conceptually similar to (although more complicated than) maintaining the imports in a Java file. Basically, when I'm editing Java I never ever have to see the imports or do anything manual. When I add a new class I need the IDE adds them, and when I no longer use it the IDE takes it away and tidies the imports up. The import section of the code is generally folded by default so I never even see them. Of course this is relatively complicated behind the scenes but as a user I don't care - that's why I'm using the IDE. I'm not there yet with Clojure since I don't remove the classes automatically, but I'll do that soon, or at least mark the class as unused and provide a quickfix to remove it. That's the holy grail for ns management in Clojure I think. It may or may not be possible with a nice UI, time will tell.
Oh, and with imports, at least, if you modify them by hand the IDE cooperates nicely with your modifications. If you then edit outside the IDE, right, you have to do all this by hand and you realise why you now use an IDE because you've totally forgotten the pain involved. However we shouldn't use that as an argument not to add this functionality, if we did we'd all be using notepad still :-) Of course, all this is orthogonal to removing :use from the language, which I don't have strong feelings about except for my rant yesterday about how complicated it can get to be. Sadly, as a tool developer I'll have to support both for the foreseeable future anyway. On 28 July 2013 12:36, Lee Spector <lspec...@hampshire.edu> wrote: > > On Jul 27, 2013, at 3:49 PM, Laurent PETIT wrote: > > > > 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. > > This sounds interesting but also pretty complicated. What if I type a > function name without using code completion? Will it still change the ns > declaration? When? What if I delete a function call? Will it prune the ns > declaration? What if I have some reason to make manual edits to the ns > declaration beyond what the automatic system can handle... will manual and > automatic updates to the ns declaration fight with each other? And if I end > up relying on this then I'll be dead in the water if I ever have to edit > code outside of the IDE. > > Much cleaner and simpler just to leave :use alone! :-) > > Of course this might be useful for some people and in some contexts even > if :use is still supported, as might other forms of automatic ns > management. (As I mentioned, I'd love to be able to get away with less > typing than even :use requires, and to offload more of this plumbing work > to the language/system.) But if the goal here is to ease the pain of > getting rid of :use then it'd sure be a lot simpler just to not get rid of > :use. > > -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.
