I do not think we should change the example. I do not want people to falsely believe that they can any expectation of the modules provided by a package from its name. In particular, your comment about this being "strange" is not supported by the package system's promises.
Jay On Sunday, November 30, 2014, Matthew Flatt <mfl...@cs.utah.edu> wrote: > We should change that example. It would indeed be strange for package > named "tic-tac-toe" would introduce a `data/matrix` module, and the > documentation really shouldn't suggest that it makes sense for a > package to introduce overlaps that are not reasonably expected from the > package name. > > > There are plenty of real examples where it's sensible for different > packages to introduce modules in overlapping collections, though. > Sometimes, it's because different packages implement different facets > of a conceptual whole, such as "math-lib", "math-doc", and "math-test" > all extending the "math" collection. Sometimes, it's more a mater of > history, such as "compatibility-lib" extending several different > collections. And then there are example that you might classify as > either of those or as a third kind, depending on how you look at it: > "draw-lib" adds `racket/draw`, and "gui-package-manager" adds > `pkg/gui`. > > > The "data" collection is among those that were intended to be extended > by multiple packages. Whether that's really a good idea remains to be > seen, but that's why "data" shows up as an example in the manual. > (Again, though, no one would expect a "tic-tac-toe" package to > introduce a new module in "data".) > > > At Sun, 30 Nov 2014 10:22:49 -0500, Neil Van Dyke wrote: > > Given the example from the documentation, of the `tic-tac-toe` package > > and "conflicts" (quoted at end of this email), instead, why isn't the > > norm to do: > > > > (require tic-tac-toe) > > > > Or, when necessary: > > > > (require tic-tac-toe/matrix) > > > > Why, when one installs a package named `tic-tac-toe`, would one be > > referencing modules of the package as `data/matrix`? > > > > I don't recall ever seeing a situation in which I wanted different > > third-party Racket packages to be stomping over each other's > > module-naming namespaces. > > > > For people who want to release lots of well-behaved reusable packages, > > using good practices, with minimal effort and head-scratching, things > > like this are a problem. > > > > > 2 Package Concepts > > > > > > A package is a set of modules in some number of collections. Modules > > > installed using the Racket package manager are required like any other > > > modules. For example, if the package tic-tac-toe contains the module > > > "matrix.rkt" in a "data" collection, then after tic-tac-toe is > installed, > > > > > > (require data/matrix) > > [...] > > > 2.5 Package Conflicts > > > > > > Two packages are in conflict if they contain the same module. For > > > example, if the package tic-tac-toe contains the module file > > > "data/matrix.rkt" and the package factory-optimize contains the module > > > file "data/matrix.rkt", then tic-tac-toe and factory-optimize are in > > > conflict. > > > > > > A package may also be in conflict with Racket itself, if it contains a > > > module file that is part of the base Racket implementation. For > > > example, any package that contains "racket/list.rkt" is in conflict > > > with Racket. > > > > > > For the purposes of conflicts, a module is a file that ends in ".rkt", > > > ".ss", or ".scrbl". > > > > Neil V. > > > > _________________________ > > Racket Developers list: > > http://lists.racket-lang.org/dev > _________________________ > Racket Developers list: > http://lists.racket-lang.org/dev > -- Jay McCarthy http://jeapostrophe.github.io "Wherefore, be not weary in well-doing, for ye are laying the foundation of a great work. And out of small things proceedeth that which is great." - D&C 64:33
_________________________ Racket Developers list: http://lists.racket-lang.org/dev
