On Thursday, April 05, 2012 15:30:17 Steven Schveighoffer wrote: > On Thu, 05 Apr 2012 14:24:10 -0400, Jonathan M Davis <jmdavisp...@gmx.com> > > wrote: > > On Thursday, April 05, 2012 09:49:59 Steven Schveighoffer wrote: > >> On Thu, 05 Apr 2012 09:23:25 -0400, Timon Gehr <timon.g...@gmx.ch> I > >> suppose the only thing we don't get is being able to have a module and a > >> package with the same FQN. I don't see that being a major issue. > > > > What doesn't work is being able to turn a module into a package with the > > same > > name. Right now, we could create a std.alg package with sub-modules > > containing > > all of std.algorithm's functionality and change std.algorithm to pubicly > > import them all, but you can't turn std.algorithm itself into a package > > without breaking code. > > But so what? nobody has any code like: > > import std.algorithm.sort; > > So who cares where that module goes? I agree it would be ideal to put it > there, but I don't think it's strictly necessary. And there is no need > for the shortcut for fully qualified names. > > > So, the whole point of this proposal - to seemlessly allow the > > transition of a > > module to a package in place - _does_ require a language/compiler change. > > I don't see how. Just move the code into another module and publicly > import that module from std/algorithm.d. Problem pretty much solved.
The issue is code organization. If you want to split up std.algorithm (or std.datetime or whatever) into multiple modules, you have to create a new package with a completely different name with no connection to the original save for the fact that the original publicly imports it. For instance, with the work that I've done thus far on splitting std.datetime, I've had to create a std.dtime package to hold the modules and have std.datetime pubicly import them. This automatically creates the issue of what the difference between them is (for anyone new to Phobos) and does not indicate their relation at all in the hierarchy. It would be much cleaner to be able to turn std/datetime.d into std/datetime/ with a package.d in it along with the new modules. No, we don't _have_ to do something to make it so that std.algorithm can be turned into std/algorithm/ while still not breaking code. But it would be very nice. Certainly, I don't understand why this DIP would ever have been proposed if Andrei didn't find it valuable. > BTW, importing a directory was already proposed in DIP15. > http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP15 Yes, but having a package.d with the public imports gives you much finer- grained control over what gets imported, and DIP15 doesn't solve the problem of fully qualified uses of std.alorgithm.sort not breaking when std.algorithm.sort gets moved to something like std.algorithm.sorting.d. So, DIP15 doesn't work as a means of seemlessly breaking up a module. It just _mostly_ works as one (since people usually don't fully qualify symbols). Also, package.d would give us a means for documenting a package, which I would very much like to be able to do. Having std.datetime give an overview of the std.dtime package is definitely worse than having a means of having the package document itself - which the package.d file should be able to give us. The package.d portion of DIP16 allows a means of controlling what importing a package would mean, it provides a means of turning a module into package in place, and it potentially provides a way of documenting a package - all of which are valuable. Whether they're valuable enough to merit a language change is obviously up for debate, but certainly, as the designer and primary maintainer of one of the main targets for being split up, I very much like the idea of being able to split up a module in place rather than having to create a new package with a new name with no obvious relation to the original. - Jonathan M Davis
