On Thu, Jun 6, 2013 at 8:17 AM, Sam Tobin-Hochstadt <sa...@ccs.neu.edu> wrote: > On Thu, Jun 6, 2013 at 10:00 AM, Matthew Flatt <mfl...@cs.utah.edu> wrote: >> >> >>> What I'd like is to have single-collection being the default [...] >>> >>> So here is a demo patch attached to precise what I mean (without >>> test, would have taken me way too much time). Because it considers >>> that single-collections are the default, it is backward incompatible. >>> If info.rkt exists, it looks for 'multi-collection, and otherwise >>> looks for the 'collection-name string. >> >> I could go along with this, as long as (most?) everyone agrees, and as >> long as package authors are willing to update existing packages. > > 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. Jay -- Jay McCarthy <j...@cs.byu.edu> Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _________________________ Racket Developers list: http://lists.racket-lang.org/dev
