digitalmars.D - DIP 37: Importing Packages as if They Were Modules
- Jonathan M Davis (14/14) May 05 2013 This DIP (which is similar to DIP 15) was discussed with Walter and Andr...
- deadalnix (4/24) May 05 2013 I would prefer to find the package file in std/datetime.d so no
- Daniel Murphy (8/36) May 05 2013 Using 'package' means you can't actually explicitly name the module. No...
- Timothee Cour (7/7) May 05 2013 under DIP37, assuming Clock is under std.datetime.common, will we have:
- deadalnix (7/18) May 06 2013 That is true. In D, ANY change can cause a breakage. Yes, even
- deadalnix (5/10) May 06 2013 The argument is not new. For instance what if one want to
- Daniel Murphy (3/4) May 06 2013 Wow I need sleep.
- Jonathan M Davis (22/31) May 06 2013 Yes. This came up when we were discussing it at dconf, and it was decide...
This DIP (which is similar to DIP 15) was discussed with Walter and Andrei at dconf 2013: http://wiki.dlang.org/DIP37 They verbally approved it in that discussion and it has already been implemented by Daniel Murpy (though it hasn't been merged in yet): https://github.com/D-Programming-Language/dmd/pull/1961 There is also an enhancement request for it: http://d.puremagic.com/issues/show_bug.cgi?id=10022 The idea is very simple and does not require large changes to the compiler to work as it mostly takes advantage of what the module system and imports already do. However, it probably does merit having an actual DIP for it as well as a public discussion, so I've created a DIP for it and am opening this thread so that we can discuss it. - Jonathan M Davis
May 05 2013
On Monday, 6 May 2013 at 03:16:31 UTC, Jonathan M Davis wrote:This DIP (which is similar to DIP 15) was discussed with Walter and Andrei at dconf 2013: http://wiki.dlang.org/DIP37 They verbally approved it in that discussion and it has already been implemented by Daniel Murpy (though it hasn't been merged in yet): https://github.com/D-Programming-Language/dmd/pull/1961 There is also an enhancement request for it: http://d.puremagic.com/issues/show_bug.cgi?id=10022 The idea is very simple and does not require large changes to the compiler to work as it mostly takes advantage of what the module system and imports already do. However, it probably does merit having an actual DIP for it as well as a public discussion, so I've created a DIP for it and am opening this thread so that we can discuss it.I would prefer to find the package file in std/datetime.d so no change is required in lookup rules. Whatever the naming convention is, I'm all for it.
May 05 2013
"deadalnix" <deadalnix gmail.com> wrote in message news:vyytwcgofkilgcyoqwvf forum.dlang.org...On Monday, 6 May 2013 at 03:16:31 UTC, Jonathan M Davis wrote:Using 'package' means you can't actually explicitly name the module. Not sure why you'd want/need to... With the lookup rules this shouldn't actually be a problem. The of your suggestion downside is that you then don't have the entire package contents inside the package directory. I think that would be a pain.This DIP (which is similar to DIP 15) was discussed with Walter and Andrei at dconf 2013: http://wiki.dlang.org/DIP37 They verbally approved it in that discussion and it has already been implemented by Daniel Murpy (though it hasn't been merged in yet): https://github.com/D-Programming-Language/dmd/pull/1961 There is also an enhancement request for it: http://d.puremagic.com/issues/show_bug.cgi?id=10022 The idea is very simple and does not require large changes to the compiler to work as it mostly takes advantage of what the module system and imports already do. However, it probably does merit having an actual DIP for it as well as a public discussion, so I've created a DIP for it and am opening this thread so that we can discuss it.I would prefer to find the package file in std/datetime.d so no change is required in lookup rules. Whatever the naming convention is, I'm all for it.
May 05 2013
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.
May 05 2013
On Monday, 6 May 2013 at 06:18:40 UTC, 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.That is true. In D, ANY change can cause a breakage. Yes, even the one that suddenly allow new constructs because of potential existence of is(typeof(previously invalid now valid code)) . We should test this kind of change on actual codebases to assert what is the breakage. But I expect it to be small in this case, so it is worth it.
May 06 2013
On Monday, 6 May 2013 at 04:36:17 UTC, Daniel Murphy wrote:The of your suggestion downside is that you then don't have the entire package contents inside the package directory. I think that would be a pain.The argument is not new. For instance what if one want to distribute a lib as a zip file ? It convinced me at the time. I think putting everything in the same folder won't solve the problem as package folder hierarchy is required anyway.
May 06 2013
"Daniel Murphy" <yebblies nospamgmail.com> wrote in message news:km7c00$2mfs$1 digitalmars.com...The of your suggestion downsideWow I need sleep.
May 06 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
May 06 2013