Kris,
I disagree. Whether we're deprecating an extension or a subset of > functions, the practical impact is pretty much the same. As for moving it > to PECL, why are we even discussing that here? It's completely outside the > scope of this RFC. I imagine moving it to PECL would make the most sense > when the time comes, but we shouldn't get ahead of ourselves. We should > deprecate it first, then when the time comes (i.e. 6.0) we can figure out > where to dump its carcas. > Actually, it is very much within the scope of this discussion. Case in point, take a look at 5.3.0. The following extensions were moved to PECL: - ext/dbase - ext/fbsql - ext/fdf - ext/ncurses - ext/mhash (BC layer is now entirely within ext/hash) - ext/ming - ext/msql - ext/sybase Now you could make the argument that they weren't as used as ext/mysql. But they were removed from core without raising E_DEPRECATED first. So there definitely is precedent to remove without deprecating first. So it's completely within the realm of discussion here. Either way, our common goal here is to get people to stop using ext/mysql > now so that we can trash it when the time comes. And as far as that goes, > I think that what happened with magic_quotes and Drupal is a perfect > example of how deprecation can effectively push devs to act when docs and > "get the word out" campaigns aren't enough. > The problem with this statement is that you're indicating something that didn't happen. "get the word out" campaigns have not happened on an official level for ext/mysql. The wording in the docs is light at best. There has been very little effort from the side of the project to say "get off it now". And that's what some of us have against this concept of raising E_DEPRECATED in 5.5 (or possibly ever)... Anthony
