On Tuesday 12 July 2011 23:38:10 Adam D. Ruppe wrote: > Jonathan M Davis wrote: > > The current plan is that _everything_ which gets deprecated will > > be removed. > > What's the reason for removing things? Surely it's not disk space! > > > Anyway, let's look at the three categories. While I hate change, > there are two kinds of change: trivial and painful. Remember, D > isn't a useless piece of junk dynamic language - trivial changes > are easy to find and easy to change with confidence. > > Painful changes though, are, well, painful. > > > 1. Renaming stuff to follow Phobos' naming conventions. > > These are trivial, just change it. It's like ripping off a band-aid. > The compiler will tell you what broke and how to fix it (the spell > checker ought to catch camelcase changes without keeping the old > name). > > Do it fast, feel the brief pain, and move on.
Hmm. I don't think that Walter would be very happy about that, since it does immediately break code, but as long as the name change is easily found by the spellchecker, it wouldn't be a big deal to fix. So, under at least some circumstances, that may be acceptable. Regardless, it could be grounds for making the deprecation cycle for renaming relatively short instead of around 1 year as is the current plan for deprecation in general. > > 2. Small redesigns of older functionality. > > These should be reasonably trivial fixes too, but might warrant > deprecating the old on a case by case basis. If it's mindless > to change though, just rip that bandage off. > > Just make sure that the types are different or something, while > still super easy to change, so the compiler will point it out to you. > > > 3. Full module redesigns due to the need of serious improvement > > This is where the pain comes in, since instead of spending 15 > minutes running a mindless find/replace when the compiler tells > you to, it requires gutting a lot of code and rethinking it, > converting databases, etc. > > These should ideally aim to redesign the internals, but keep the > same interface. Maybe adding to it or writing the old as an > emulation layer over the new. > > This is preferred, since then new and old exist together. It avoids > actually breaking anybody's code. > > > If that's impossible though, this is the most likely candidate > for deprecation. Unlike a name change, it isn't easy to change, > so a compile error is more likely to mean reverting dmd versions > than actually changing it. At this point, I expect that the module rewrites are going to generally be full-on, completely incompatible rewrites. Fixing the API is one of the major reasons for the rewrites (particularly when converting a module to being range-based as is going to occur with std.stream), so just changing the implementation isn't going to cut it. It may be that in some cases, it's essentially a rewrite of a broken implementation, but I'm not aware of any such case at the moment. These are definitely cases, however, where the full deprecation cycle is going to be used, so there should be plenty of time to fix code. Hopefully, these changes get done fairly soon, but some of them don't seem to be going anywhere yet in spite of major discussions about them (e.g. std.stream). They're also the most work to do, so while I would expect most of the #1 and #2 types of deprecations to occur fairly soon for the most part, the full module rewrites could take a while, which is unfortunate. Off the top of my head, I know that std.xml, std.stream, std.path, and std.json are going to get rewrites on some level, and std.container could get some major rewrites depending on what Andrei does with memory management in it, though what it needs primarily is new containers. Also, Andrei thinks that std.encoding is a failed experiment which needs to be redone, so that's probably going to need to be rewritten at some point. And as I understand it, all of those except for std.stream and std.encoding have someone actively working on them (though maybe Andrei has been working on std.stream too; I don't know). So, hopefully it won't be too much longer before they're done, but it could also be a while unfortunately. So, anyway, there are some module rewrites to be done, and they're likely to be pretty major for better or worse. But once those are done, with the review process vetting new modules, deprecation issues like these should be far rarer, and Phobos should be heading towards stability. - Jonathan M Davis