DIP16: Transparently substitute module with package

Jonathan M Davis jmdavisProg at gmx.com
Mon Apr 9 10:05:04 PDT 2012


On Monday, April 09, 2012 08:55:27 Steven Schveighoffer wrote:
> On Fri, 06 Apr 2012 20:25:23 -0400, Jonathan M Davis <jmdavisProg at gmx.com>
> 
> wrote:
> > DIP15 doesn't fix the explicit path problem though. You can't change
> > std/algorithm.d into std/algorithm/ (with sorting.d, search.d, etc.)
> > without
> > breaking code. You could make std/algorithm.d publicly import std/alg/*
> > and
> > then DIP15 would allow you to import std.alg to get all of its
> > sub-modules,
> > but you're still forced to use a module to publicly import symbols as
> > part of
> > a migration path, and you can't split a module in place.
> 
> I think either you or I am missing something.
> 
> In DIP15, if you define std/algorithm/_.d, and then import std.algorithm,
> it imports std/algorithm/_.d, which then 1. publicly imports other
> modules, and 2. aliases symbols to the name std.algorithm.symbol. At
> least, this is how I understand the intent. It seems equivalent to me to
> the package.d proposal, it's just using _.d instead of package.d.
> 
> If you import std.algorithm.sorting, and try and use std.algorithm.sort,
> yes it will not work. But this does not break existing code (which does
> not import std.algorithm.sorting), and I find it odd that we want to make
> std.algorithm.sort work if you don't import std.algorithm.

Okay. I reread DIP15 again. I guess that I scanned over it too quickly before 
and/or misremembered it. I had understood that it was proposing that 
importing std.algorithm where std.algorithm was a package would be the
equivalent of importing std.algorithm.* in Java and that there were no extra
files involved. So clearly, I've been misunderstanding things here.

So, yeah. DIP15 is basically the same as DIP16 except without the std.sort 
nonsense and the fact that it uses _.d instead of package.d. Using package.d 
has the advantage of package being a keyword, making it so that no one is 
going to accidentally create a module that will be treated specially, but it 
has the downside of likely requiring more special handling by the compiler. I 
don't really care which we pick though.

My main point though, misunderstandings aside, is that it would be _really_
nice to be able to split up  a package in place and that without an
enhancement of some kind, we can't do  that without breaking code. DIP15
appears to fit the bill quite nicely in that regard though. The part of
DIP16 which is really bad is the std.sort stuff which. Public importing
combined with either the first part of DIP16 or with DIP15 seems to take
care of the problem quite nicely.

- Jonathan M Davis


More information about the Digitalmars-d mailing list