On Tue, 06 Sep 2011 14:21:52 -0400, Brad Anderson <e...@gnuk.net> wrote:
On Tue, Sep 6, 2011 at 8:51 AM, Andrei Alexandrescu <
seewebsiteforem...@erdani.org> wrote:
Probably. At any rate, what I now think as a promising path is with new
module names. Let's leave the likes of std.xml and std.json in peace,
then
pick a naming convention for the new ones and create whole new modules
replacing them. Then people who are ready for the migration change
import std.xml;
with
import std.some_naming_convention_**involving_xml;
Along these same lines I'm wondering why not simply call this new module
std.io rather than use the existing name std.stdio? It'd avoid the code
breaking issue and help reflect that this new module isn't based around
C's
stdio FILE (at least that's what I gather). Also, the code is written
from
scratch so that's another reason for why I don't think it should have the
same name. The only reason I can think of is if it provided significant
improvements over the existing std.stdio without causing massive
breakage.
I think for something like std.xml which is somewhat of a standalone
module, this is fine.
However, i/o is used *everywhere*. It's the same situation with
std.datetime. We can't duplicate all functions which deal with i/o in
order to cater to both the stdio and the std.io folks, I think it's a
waste of time, and it also looks bad.
But I think I have come up with a plan (obviously not the one posted here)
which keeps stdio's API compatible, yet can use the new stuff I've written
if desired. i.e. provides improvements over the current std.stdio without
causing massive breakage.
Coincidentally, std.io is the name I chose for the new module ;)
I'll post again when it's something that can be shared. I want to get all
my ducks in a row first (obviously more than I did this time...)
-Steve
