DIP16: Transparently substitute module with package

Steven Schveighoffer schveiguy at yahoo.com
Thu Apr 5 12:30:17 PDT 2012


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.

BTW, importing a directory was already proposed in DIP15.  
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP15

-Steve


More information about the Digitalmars-d mailing list