> 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.
Back in the days of Cobol, before it got renamed to Java,
we used to construct hierarchical databases. For those who
don't know about them, they would specifiy the path to every
element in the database in the name of the element. Thus, you
would say
world.country.company.site.disk.dbname.dept.bldg.aisle.office.person
or some such.
It was argued that this was necessary to ensure that
you always got a unique element and that programs would not clash.
It was also very efficient since the worldwide path to a point
was always unique (as opposed to the horribly inefficient idea
of using table and relational algebra to look up stuff at runtime!
Why the ambiguity will cause world confusion and the runtime will
be impossibly long! Just write out the long name! Sigh.)
There are a couple of items worth mentioning. First, notice
that everything is fine until the world changes. Now there
are hardcoded legacy assumptions built into the name (e.g.
the person is in a different building so we have to reformat
the database to pay them). Consider that the Java naming
convention does that... java.sun.com ... who is "sun"?
I never heard of them.
Second, but similar, should I name my classes java.daly.tim.freesource?
Suppose I get married and change my name? Suppose someone with a
similar name writes a package. Does my son have to write
java.jr.daly.tim.freesource?
Third, suppose I refactor my program. Now I have to rename every
class to fit the new hierarchy. But that will break old programs
that use my package. Who could possibly want to refactor deep
enough to shuffle classes?
Fourth, this hierarchical thinking strongly encourages making
functions that are class-specific. Thus you find that java has
hundreds of sorts, one per class.
Fifth, one writes the long.drawn.out.name to satify the
compiler's inability to find anything despite the class name
being unique. In fact, the compiler is insisting that your
class name match the name of the file and it STILL insists
that you use unique names so it doesn't have to search the
filesystem. The side-effects of this are that your class hierarchy
is rigid (see refactoring above), the name assumes a hierarchical
file system, and the ultimate issue... the user has to use an IDE
to find something simple as a sort.
Sixth, programs rarely need to deal with the whole world.
Why would you have qualifiers on a per-company basis just
to guarantee uniqueness of the name of your sort function?
In lisp one ends up with hundreds of functions in the same
namespace. Because the functions are not type-specific
they tend to be very broad and general. It is rare to have
more than one sort and people don't generally write sort
functions since they are too standard.
A simple namespace qualifier, like fs, is sufficient to
handle large, general purpose packages which contain functions
to handle file systems.
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.
Tim Daly
--
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
