Hi, Am 19.07.2010 um 20:50 schrieb Laurent PETIT:
> Please note that it's not "impolite" in the sense that there's a policy: the > project is reloaded in the REPL when the file is saved - that's a kind of > "invitation" made by the user :-). > If you don't work from the files, but from the REPL, nothing will happen > automatically. > If you work from the files, then you simply do not save the files until > you're "happy" with the codebase. You can make several roundtrips between the > file's content and the REPL (even via keyboard shortcuts) without saving the > files. Ultimately, when you want to quit, you have to quit the REPL anyway, > and you have the option to save the files or not. > > Does this answer make sense ? It does make sense, but it doesn't work for me. I work a lot in the repl but only with files. %) If I have correctly set up file in the classpath, where I edit my function and which a save quite often. (Sometimes in a broken state.) In the repl I only define small mock functions for quick testing of the functions which were defined in the file and sent over via code evaluation. If you don't want to settle on one way, I would suggest, that you make the behaviour configurable. > There's also the problem of "I save file A", and all project namespaces are > reloaded as well. By maintaining a dependency graph of the namespaces > relationships (easily obtained dynamically via the REPL), I may be able to > only reload the expected namespaces. Some may see this as a feature - > ensuring that all functions which depend on namespace A macros are recompiled > -, I can see that some may see this as a recipe for disaster if reloading the > namespaces also reloads global-var-as-data contents. Proper use of defonce > may help there ? This is something I would support. I think it should be easy to get a clean system after some changes. Then all changed macros would be recompiled and the multimethod wouldn't require the defonce semantics, since it's easy to reconstruct the methods. I could imagine to provide such a „reload dependees“ feature also in VimClojure. Then everyone can choose whether to use it, or not. Sincerely Meikel -- 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
