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.
Look at what was deprecated and removed so far. We deprecated register globals and magic quotes. The process worked there. But was it because of the process? Or was it because those features were already dead by that point. Think of this: when 5.3 shipped (introducing E_DEPRECATED for those features), how many current versions of open source tools relied on those features? None. Now, you could point to call-time-pass-by-reference as well. E_DEPRECATED was added in 5.3 for it. But most of the projects that used it only used it in a few minor places. The majority of usages were relatively isolated. 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. 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. Again, my $0.02... Anthony On Tue, Nov 13, 2012 at 10:49 AM, Johannes Schlüter <johan...@schlueters.de>wrote: > > > Reinis Rozitis <r...@roze.lv> wrote: > > >> Rewriting perfectly functional mysql code to use mysqli is not a > >trivial > >> move, just as are the problems of re-writing PHP5.2 code to work > >cleanly > >> on 5.4. ISP's are stuck between keeping customers - who are most > >likely > >> not even very computer literate - working while fighting the problems > >that > >> changes such as removing mysql will cause them. > > > > > >I wonder if there have been any plans or suggestions (while dropping > >the > >old ext/mysql code) to provide some sort of seamless > >migration/alternatives > >(similar way it has been done in case of libmysql and mysqlnd)? > >In short - just aliasing the old mysql_* to mysqli_* functions (as most > >used > >like _query, _fetch_row/assoc have just mixed variable order)? > > > > Reimplementing ext/mysql inside PHP makes no sense. The result of this > would be (almost) the exact same code as we have. (ext/mysql is a exremely > small wrapper over libmysql/mysqlnd only special thngs are pconnect, auto > connect and reusage of default connection) What one might try to do is > changing ext/mysql to not use a resource but an mysqli object, then users > might swich module by module, instead of breaking the application > completely. But I fear we will introduce many bugs that way as this is a > quite huge patch. An alternative approach might be to reimplement mysql_* > functions using PHP userland code based on mysqli. Then users can load that > lib (php.ini autoprepend_file) for compatibility and bugs can be fixed > relatively simple (no C needed, no PHP release needed, ...) but again: > writing such a lib is a relatively huge project. > > In my opinion we tell users as good as we can that ext/mysql is deprecated > for some time, if we really want to get rid of it, we have to add > E_DEPRECATED and then remove it.Waiting a year more won't change much, > there will always people who hit it. > > johannes > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
