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