Thread overview
DIP 37: Importing Packages as if They Were Modules
May 06, 2013
Jonathan M Davis
May 06, 2013
deadalnix
May 06, 2013
Daniel Murphy
May 06, 2013
Timothee Cour
May 06, 2013
deadalnix
May 06, 2013
deadalnix
May 06, 2013
Daniel Murphy
May 07, 2013
Jonathan M Davis
May 06, 2013
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 06, 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 06, 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:
>> 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.

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.


May 06, 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 06, 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 downside

Wow I need sleep.


May 07, 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