Just to be clear. I don't think that "tic-tac-toe" and "data/matrix" are the important thing in this example. The important thing is that the package name and the module don't share a prefix. Another good example would be something like "graphs" and "data/fib-heap" or something where it may to be easier to imagine the connection between the purpose of the package and a particular module provided.
Jay On Sun, Nov 30, 2014 at 12:16 PM, Jay McCarthy <jay.mccar...@gmail.com> wrote: > 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 -- 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