On Thu, 05 Apr 2012 17:43:24 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
On 4/5/12 4:26 PM, Steven Schveighoffer wrote:
On Thu, 05 Apr 2012 17:00:56 -0400, Jonathan M Davis
<jmdavisp...@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.
Of course you *can* do this. I think you mean "and allows one to refer to
the fine grained module as if it were imported from the top-level module".
I don't think that benefit is very great. Why shouldn't we expect people
to use the module name they actually imported to refer to a module? If
you want selective import, we have:
import std.algorithm : sort;
I think the real benefit to splitting up the module comes from being able
to draw clear lines between which pieces of a large module are related.
I feel like most people will still import the main package module, and not
the submodules. I don't think I ever wrote a piece of java code that
didn't have:
import java.io.*;
I keep coming back to std.container. Already it's large, and full of
unrelated types. It's only going to get worse.
Now, I fully agree that having some way to import a package by itself
without having to import all its modules would be ideal (as well as
splitting a large module into submodules that live in the same
namespace). I think DIP15 has that covered.
-Steve
