On Thu, 05 Apr 2012 17:00:56 -0400, Jonathan M Davis <[email protected]>
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.
Look at std.bigint, which imports modules from std.internal.math. Nobody
ever imports std.internal.math.??? because they just import std.bigint.
BTW, importing a directory was already proposed in DIP15.
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP15
Yes, but having a package.d with the public imports gives you much finer-
grained control over what gets imported, and DIP15 doesn't solve the
problem
of fully qualified uses of std.alorgithm.sort not breaking when
std.algorithm.sort gets moved to something like std.algorithm.sorting.d.
I think you are forgetting that all current code imports std.algorithm,
which will register the symbol std.algorithm.sort via public import. No
code will break, even if it uses FQN.
The only way to "break" code is to write new import statements. I don't
think anyone will do that unknowingly.
-Steve
