Uri class and parser

[Jonathan M Davis]

On Sunday, October 28, 2012 11:32:14 Jens Mueller wrote:
> Walter Bright wrote:
> > On 10/26/2012 2:13 AM, Jonathan M Davis wrote:> There's definitely
> > some truth to that, but Walter in particular seems to be
> > 
> > > against breaking anything period.
> > 
> > We have a number of fed up developers and abandoned, dead projects
> > because of breaking changes.
> > 
> > It MUST STOP.
> 
> Can you point me to the data that you base you conclusions on?

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 wonder whether each breaking change can be considered equal.

I think that you can talk Walter into breaking changes if doing so is very 
beneficial (e.g. we're looking at removing opEquals, opCmp, toHash, and 
toString from Object because doing so would have huge benefits with regards to 
const-correctness among other things), but something as simple as renaming a 
function or module definitely isn't going to sit well with him, pretty much 
regardless of how much code uses it or how simple a change it is.

> And what's the plan to improve Phobos then? Just have two modules?

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.

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