There's a close parallel in Python, where the same issue comes up of typically using several modules or packages in a source file and the language offers a way to import the functions and classes of those modules in such a way that they can be used without any syntactic marker of their origin. For years I've used the Google style guideline <https://google-styleguide.googlecode.com/svn/trunk/pyguide.html#Imports> which says "Use imports for packages and modules only", as distinct from functions, classes, etc., and the justification is "The source of each identifier is indicated in a consistent way; x.Obj says that object Obj is defined in module x".
I've found that when reading code that I haven't written it lowers the friction for understanding just a little bit but that's multiplied by roughly the number of names in the source code. It makes it (mostly) self-evident whether an identifier names a concept from the file I'm looking at, or somewhere else. And if it's from somewhere else, it says right there where that other place is. It's a significant advantage and I think the same advantage applies to clojure source code. On Sun, May 17, 2015 at 8:28 AM, Colin Yates <colin.ya...@gmail.com> wrote: > As stated in the article, I find the extra context of using :as aids > maintenance more than you might expect. The only time I use refer is > if the referred vars are conceptually owned, or the context is > implicit by the name space using them. For me it is about > responsibility and ignorance. :as implies distance/ignorance, :refer > implies closeness/knowledge. > > A concrete example, in my use-case tests I refer most vars from > clojure.test for convenience but the thing being tested is aliased as > 'sut'. I could swallow referring the forms being tested in the test > case as well but I am used to the convention of 'sut' (subject under > test). > > > On 17 May 2015 at 16:23, Akiva <akiva.sch...@gmail.com> wrote: > > Makes sense. I guess my other question then would be if there are any > > benefits to using :refer along with :as. > > > > :A. > > > > Stuart Sierra > > May 17, 2015 at 10:21 AM via Postbox > > Just like the rest of the article, it's about readability. With `:refer` > you > > don't know where a symbol came from when you encounter it in the middle > of > > the code. > > > > –S > > > > > > > > On Sunday, May 17, 2015 at 4:05:14 PM UTC+1, Akiva Schoen wrote: > > -- > > 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/d/optout. > > Akiva > > May 17, 2015 at 10:04 AM via Postbox > > In Stuart Sierra's article here > > (http://stuartsierra.com/2015/05/10/clojure-namespace-aliases), he > > recommends to use :refer sparingly but doesn't explain why this is a good > > idea. Only thing I could think of without putting too much effort into > it is > > that it makes it slightly more tedious when you want to use a function > from > > a namespace that hasn't been already explicitly referred. > > > > Are there no benefits other than possibly excluding function names that > > might otherwise suffer a namespace clash (assuming their namespace isn't > > being aliased already)? > > > > Thanks, > > Akiva > > > > > > -- > > Sent from Postbox > > > > -- > > 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/d/optout. > > -- > 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/d/optout. > -- 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/d/optout.
