DIP16: Transparently substitute module with package

[Jonathan M Davis]

On Thursday, April 05, 2012 15:30:17 Steven Schveighoffer wrote:
> On Thu, 05 Apr 2012 14:24:10 -0400, Jonathan M Davis <jmdavisProg at 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.gehr at 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