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
