www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP 37: Importing Packages as if They Were Modules

reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
parent reply "deadalnix" <deadalnix gmail.com> writes:
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
parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"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 05 2013
next sibling parent reply Timothee Cour <thelastmammoth gmail.com> writes:
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
parent "deadalnix" <deadalnix gmail.com> writes:
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
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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
prev sibling next sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Daniel Murphy" <yebblies nospamgmail.com> wrote in message 
news:km7c00$2mfs$1 digitalmars.com...


 The of your suggestion downside


Wow I need sleep.
May 06 2013
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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