DIP16: Transparently substitute module with package

Jonathan M Davis jmdavisProg at gmx.com
Thu Apr 5 16:14:53 PDT 2012


On Thursday, April 05, 2012 16:43:24 Andrei Alexandrescu wrote:
> On 4/5/12 4:26 PM, Steven Schveighoffer wrote:
> > On Thu, 05 Apr 2012 17:00:56 -0400, Jonathan M Davis
> > 
> > <jmdavisProg at gmx.com> wrote:
> >> On Thursday, April 05, 2012 15:30:17 Steven Schveighoffer wrote:
> >>> I don't see how. Just move the code into another module and publicly
> >>> import that module from std/algorithm.d. Problem pretty much solved.
> >> 
> >> The issue is code organization. If you want to split up std.algorithm (or
> >> std.datetime or whatever) into multiple modules, you have to create a new
> >> package with a completely different name with no connection to the
> >> original
> >> save for the fact that the original publicly imports it.
> > 
> > My view is that people will not import the smaller modules, they will
> > only ever import std.algorithm.
> 
> I think we should be looking for a solution that not only allows
> replacing module -> package transparently, but also allows people to
> import the newly introduced fine-grained modules.

Yeah. If all we want to do is continue to always import std.algorithm, then 
the DIP is more or less pointless. It's the splitting of the API among 
multiple packages while allowing the programmer to either call/import it like 
he has been or to call/import it from the new module explicitly that the DIP 
is trying to enable.

If we make it possible to split std.algorithm into multiple modules in place, 
then we avoid breaking code, keep the code organized in the same hierarchy - 
only more detailed - and allow the programmer to import on either a roughly or 
finely grained level, depending on which they prefer. And I really like how 
this could enable us to have package-specific documentation, whereas all 
documentation is currently module-specific and doesn't enable us to provide a 
page which gaves an overview of a package. That's not always necessary, but 
there are times when it would be quite nice (e.g. std.datetime).

- Jonathan M Davis


More information about the Digitalmars-d mailing list