On Sun, Nov 30, 2014 at 12:23 PM, Neil Van Dyke <n...@neilvandyke.org> wrote: > >> >> 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, the idea is that it makes sense for `data/hamt` to come from the "hamt" package, and for `data/fector` to come from the "fector" package (this is currently the case on pkgs.racket-lang.org). > If so, I don't understand why that would be > considered a good idea. Because the client of these modules shouldn't have to think about which package they belong in to use them. This gives the package developer freedom to combine or split packages without requiring code changes from clients. In general, one of the assumptions of the new package system is that metadata changes, such as dependencies, are easier to manage than code changes. This assumption is fairly pervasive in successful package systems, including extra-linguistic ones such as dpkg as well as in-language ones such as Cabal and npm. The particular mode of use, where module names splice, has been successful in a number of other communities, such as Haskell, where they have just such a Data hierarchy, and where, like in Racket, package names and module names aren't connected. This is also the case in Java packages, although the naming scheme is somewhat different. Sam _________________________ Racket Developers list: http://lists.racket-lang.org/dev
