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
