On Thu, Jun 6, 2013 at 1:42 PM, Jay McCarthy <jay.mccar...@gmail.com> wrote: > >> I am *very* strongly in favor of this -- I'd rather have >> single-collection packages than multi-collection packages, if forced >> to choose. I'm very glad that you and Laurent have done the work here. > > The main problem with this is that it brings in internal linking where > code directly refers to other packages (implementations) and not > modules (interfaces) as the default. This means we will see code like > (require jays-awesome-data-structure) rather than (require > data/awesome). I think this is bad because it makes it harder to deal > with forking, maintainers abandoning their code, splitting packages > into packages that just depend on 'jays-awesome-data-structure, rather > than implementing it internally, etc. Obviously you can still deal > with those things, but if the path of evolution we imagine starts off > with single-package-with-package/collection-name-shared, then most > packaged collections will have a package as their name.
First, I don't see why single-collection packages make things harder to deal with re-implementing a package. Imagine that I make `disassemble` a single-collection package, and someone depends on it, and then I abandon my code. You can easily create a new package that ships that collection. I think that places the burden correctly -- it's easy to create packages initially, and handling abandoned packages takes a little more work. In JavaScript, where there's a flat namespace, this works -- the Zepto library just provides the same names as jQuery, even though they're different implementations and not generic names. Second, I think this is already happening. Almost every package on `pkg.racket-lang.org` provides a new collection which is the primary code for the package, and which is named the same as the package. Sam _________________________ Racket Developers list: http://lists.racket-lang.org/dev
