Can't this be alleviated by the guidance on naming that the docs already provide? Sam <div class="gmail_quote">On Jun 6, 2013 2:30 PM, "Jay McCarthy" <<a href="mailto:jay.mccarthy@gmail.com">jay.mccarthy@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Thu, Jun 6, 2013 at 12:03 PM, Sam Tobin-Hochstadt <<a href="mailto:samth@ccs.neu.edu">samth@ccs.neu.edu</a>> wrote: > On Thu, Jun 6, 2013 at 1:42 PM, Jay McCarthy <<a href="mailto:jay.mccarthy@gmail.com">jay.mccarthy@gmail.com</a>> 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. The problem is that if you use the name "samths-disassemble" then even in twenty years, my implementation uses the collection "samths-disassemble" and not "disassemble". Jay -- Jay McCarthy <<a href="mailto:jay@cs.byu.edu">jay@cs.byu.edu</a>> Assistant Professor / Brigham Young University <a href="http://faculty.cs.byu.edu/~jay" target="_blank">http://faculty.cs.byu.edu/~jay</a> "The glory of God is Intelligence" - D&C 93 </blockquote></div>