Uri class and parser

[Jacob Carlborg]

On 2012-10-28 12:39, Jonathan M Davis wrote:

> I don't know everything that he's basing it on, but we've definitely had
> complaints in this newsgroup in the past over breaking changes (and it
> wouldn't surprise me if the folks in this newsgroup are more willing to put up
> with breaking changes than most D users). Even changes which are very popular
> can generate complaints about the code breakage that they cause. When the
> library is younger, it's not such a big deal, but as it matures, it becomes a
> very big deal. And at this point, we seem to be mature enough that we're
> moving away from the stage where it's okay to break stuff without a very good
> reason. Certainly, if we don't reach there soon, then it's going to be much
> harder for D to catch on. We'd like to get to the point that we don't  break
> anything ever (or at least don't break anything without a major version change
> of some kind).

I think we should be able to break code when there's a good reason for 
it. The RailsConf 2012 had a great talk called "Progress". I think it's 
really worth seeing:

http://www.youtube.com/watch?v=VOFTop3AMZ8

> In this case, if moving std.curl to std.net.curl isn't deemed worth the
> breakage that it would cause (and I'd be very suprised if Walter thought that
> it was), then we'd probably just keep std.curl and not move it at all. And
> while reorganizing some modules might be desirable, it really doesn't buy us
> much. I'd strongly argue that if it's not worth putting a module through the
> deprecation process in order to rename it, then it shouldn't be renamed at
> all. Having both std.curl and std.net.curl around permanently (even if one is
> basically an alias of the other), just seems like a bad idea to me. It creates
> clutter in the library. Best case, we could rename std.curl to std.net.curl,
> leaving std.curl empty save for the fact that it publicly imports
> std.net.curl, undocument std.curl completely, and then leave it around as
> undocumented, but that still creates clutter. It's just less visible.

That's way we need to stop this madness of putting all modules in the 
"std" package. BTW, this should have happened five years ago.

> Aside from there being two modules as part of deprecating one and getting code
> to use the new one (which we really do want to stop doing), then I would only
> expect us to end up with two modules if we completely revamped a module but
> didn't want to break code using the old version (e.g. std.xml - > std.xml2).
>
> - Jonathan m Davis
>


-- 
/Jacob Carlborg