On Monday, April 09, 2012 08:55:27 Steven Schveighoffer wrote: > On Fri, 06 Apr 2012 20:25:23 -0400, Jonathan M Davis <jmdavisp...@gmx.com> > > wrote: > > DIP15 doesn't fix the explicit path problem though. You can't change > > std/algorithm.d into std/algorithm/ (with sorting.d, search.d, etc.) > > without > > breaking code. You could make std/algorithm.d publicly import std/alg/* > > and > > then DIP15 would allow you to import std.alg to get all of its > > sub-modules, > > but you're still forced to use a module to publicly import symbols as > > part of > > a migration path, and you can't split a module in place. > > I think either you or I am missing something. > > In DIP15, if you define std/algorithm/_.d, and then import std.algorithm, > it imports std/algorithm/_.d, which then 1. publicly imports other > modules, and 2. aliases symbols to the name std.algorithm.symbol. At > least, this is how I understand the intent. It seems equivalent to me to > the package.d proposal, it's just using _.d instead of package.d. > > If you import std.algorithm.sorting, and try and use std.algorithm.sort, > yes it will not work. But this does not break existing code (which does > not import std.algorithm.sorting), and I find it odd that we want to make > std.algorithm.sort work if you don't import std.algorithm.
Okay. I reread DIP15 again. I guess that I scanned over it too quickly before and/or misremembered it. I had understood that it was proposing that importing std.algorithm where std.algorithm was a package would be the equivalent of importing std.algorithm.* in Java and that there were no extra files involved. So clearly, I've been misunderstanding things here. So, yeah. DIP15 is basically the same as DIP16 except without the std.sort nonsense and the fact that it uses _.d instead of package.d. Using package.d has the advantage of package being a keyword, making it so that no one is going to accidentally create a module that will be treated specially, but it has the downside of likely requiring more special handling by the compiler. I don't really care which we pick though. My main point though, misunderstandings aside, is that it would be _really_ nice to be able to split up a package in place and that without an enhancement of some kind, we can't do that without breaking code. DIP15 appears to fit the bill quite nicely in that regard though. The part of DIP16 which is really bad is the std.sort stuff which. Public importing combined with either the first part of DIP16 or with DIP15 seems to take care of the problem quite nicely. - Jonathan M Davis