On Jan 13, 2011, at 11:54 AM, Tim Daly wrote: > > Second, fs is using a singe segment namespace. I remember that > > there have been some cautions against doing that. (But not everyone > > agrees.) My understanding is that it's best for Java interop to have a > > multi-segment namespace. (Reference links below.) http://clojure.org/libs >>> A lib name is a symbol that will typically contain two or more parts >>> separated by periods. >> http://groups.google.com/group/clojure-dev/browse_frm/thread/00b1c6971c3b3394 >> >> Chas Emerick wrote: >>> First, namespacing is good. Your foobar library won't have the same name >>> as my foobar library -- and while you might think "who else would put code >>> in the same oddly-named namespace as mine?", it's a big world out there and >>> an ounce of prevention is worth a pound of cure. More strictly speaking, >>> one cannot use any class in the default package from any Java class that is >>> in a package. That is the practical issue that leads to default package >>> use being nonexistent in the Java space. And, you may not care about Java >>> interop now, but either (a) you might later, or (b) your users might, now. >>> Finally, gen-class will simply not work (last I checked) from a >>> single-segment namespace. > As a greybeard in the game, this all sounds so familiar. > The point of this post is to suggest that Clojure should > NOT adopt java naming conventions.
... > Since lisp uses naked functions there is no natural map from > functions to filenames. > > In sum, I'm suggesting that it isn't very lispy to use > hierarchical namespace naming conventions. Just to clarify my position (it's funny to see one's self quoted out of the blue from an old thread!), I'm not at all suggesting "java naming conventions" when it comes to namespacing. (Although I'd note that Clojure *is* a fundamentally hosted language, and so certain idioms do flow from that host; CamelCase naming conventions for records, types, and protocols comes to mind.) No one wants to work with com.foo.bar.baz.factory.factory.factories.Factory, etc. While there is no natural mapping between functions and filenames, surely there's *some* mapping for every project that won't run afoul of the real issues that truly can crop up with single-segment namespaces[1] but still feels natural to you. Functionally logical grouping of code never goes out of style. I'd humbly submit that single-segment namespaces are a non-solution to any naming problem you'd like to solve (outside of maximal concision perhaps, which I'd suggest is a low-value problem). Cheers, - Chas [1] If you really, really don't care about host interop, and you never, *ever* will, and you're a maestro at naming projects (yup, I'm looking at you, Phil! :-), then maybe single-segment namespaces are OK. Even then, it's worth noting that even e.g. leiningen, robert hooke, etc. don't use single-segment namespaces. -- 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
