On 14 November 2012 00:07, Anthony Ferrara <ircmax...@gmail.com> wrote: > There's one important thing that I think you all are missing here. You keep > bringing up that we should just use the normal "deprecation" process. The > problem is that the deprecation process was never designed for a feature > like this.
Serious question: what was it designed for, then? This (along with magic quotes, and register globals) was always what I had in the back of my mind when it was being discussed. <snip> > Now, look at ext/mysql. The landscape is completely different. Major > projects still rely on it in their most recent versions. Wordpress's latest > trunk uses ext/mysql. And as was said here, it's not a trivial change to > switch from mysql to mysqli or PDO. ext/mysql is still very heavily relied > upon. Last time I checked, WordPress's trunk also emulated magic quotes. Old code is old. With all due respect to the WP developers, they've made a very deliberate choice to maintain extreme backward compatibility because their plugin ecosystem demands it. Ultimately, they'll presumably emulate mysql_* in userland if it's that important to them, just as they are with magic quotes. I don't think we should let that stop us from removing dead code, or replacing APIs that promote antipatterns. > What I would suggest, is not adding E_DEPRECATED for 5.5. Instead, > officially deprecate it in the docs. Then start a PR campaign to get > projects like WP to switch away from it. Get the word out there as much as > possible. Then in 1 to 2 years when 5.6/6 is released, add E_DEPRECATED. It's already deprecated in the documentation, really — I doubt adding the actual word "deprecated" will make a difference. If we're going to drag this out, I'd rather spend an extra year with PHP actually generating warnings, as I said upthread. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
