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