DIP 37: Importing Packages as if They Were Modules

Jonathan M Davis jmdavisProg at gmx.com
Mon May 6 22:15:09 PDT 2013


On Sunday, May 05, 2013 23:18:31 Timothee Cour wrote:
> under DIP37, assuming Clock is under std.datetime.common, will we have:
> 
> fullyQualifiedName!Clock == std.datetime.common.Clock,
> whereas currently we have: fullyQualifiedName!Clock == std.datetime.Clock.
> 
> Likewise with moduleName!Clock, packageName, __MODULE__ etc, which
> will have a different value compared to currently.
> So this will result in potential code breakage for code that relies on
> that. Just something to think about.

Yes. This came up when we were discussing it at dconf, and it was decided that 
that was not a big enough reason to not do this. When you're doing module 
introspection, you're basically looking at the implementation details of a 
module, and it's unreasonable to expect those not to change. Also, well-
written introspection will often work anyway, because it won't rely on what 
the result of the introspection is. It'll just use it. And even in a case 
where you're doing something like getting a list of symbols in a module, if 
it's done recursively enough, then you'd still get them all when the module 
became a package. Also, module introspection like that probably wouldn't be 
done often to a module in the standard library. It's more likely to be done 
when you're doing something fancy with your own code, in which case, you're in 
full control of both the inspector and the inspectee and would be better able 
to judge and control the consequences of such changes. But I wouldn't expect 
many modules in Phobos to be affected by this anyway. There's a good chance 
that both std.datetime and std.algorithm would be split up, but I'm not aware 
of any other modules where people have been asking for that. In the long run, 
the value of this DIP will primarily be in being able to do the all.d idiom 
more cleanly, but in the short run, it will allow us to split up std.datetime 
and std.algorithm without breaking anything other than possibly something 
which is doing module introspection on them for some reason.

- Jonathan M Davis


More information about the Digitalmars-d mailing list