Jay McCarthy wrote on 11/30/2014 12:30 PM:
On Sunday, November 30, 2014, Neil Van Dyke <n...@neilvandyke.org
<mailto:n...@neilvandyke.org>> wrote:
Jay McCarthy wrote on 11/30/2014 12:13 PM:
The documentation cited is making clear that there is NO
connection between the name of a package and the provided
modules. There is no such thing as a package namespace.
I'd really like there to be. For third-party packages.
I do not know what a third party package is.
I'm thinking of *non*-core-Racket-developers. Who have different needs
than core Racket developers. It's good that Racket is blurring the
distinction, but the needs still aren't necessarily the same. I say
"third-party" as shorthand familiar to me, but perhaps there's a better
term.
Packages may find it convenient to build and provide reusable
functionality with many organizational names. This is
particularly true of "data", as many packages may have useful
data structures.
Of course, as such support code becomes very useful and
developed, it makes sense to sprin it off into its own package.
Are you saying that `data` is some kind of classification of "what
this module is about", and in this case specifically, "this
module, which is part of some more specific package, happens to be
regarding general-purpose data structures, so we're putting it
over here in the `data` area of a shared namespace hierarchy"?
Yes, although this is just for the benefit of search and reading docs;
it has no technical enforcement.
If so, I don't understand why that would be considered a good idea.
It is a principle to create general purpose reusable code in the
package ecosystem rather than little archipelagos with lots of private
code that gets duplicated and has clever names.
I keep wanting to encourage lots-and-lots of packages, and they can be
packaged and released in a very lightweight yet well-conceived manner.
To go back to your example, if it's a useful general-purpose data
structures library, then that's another package, which should be very
easy to do. If the package author isn't ready to split it out, then
they're not ready to split it out, so no sense talking about it. As far
as I can tell, in no case is this `data` namespace relevant.
Side note: I really don't think ontological classification of package
topics belongs in package names. Topical classifications evolve over
time, and independent of the objects themselves. Classifications belong
in directories, not in names.
Neil V.
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
