On 20.06.2010, at 12:01, Ulf Wendel wrote: > Johannes Schlüter schrieb: >> On Sat, 2010-06-19 at 12:45 +0200, Sebastian Bergmann wrote: >>> Am 19.06.2010 11:33, schrieb Patrick ALLAERT: >>>> What are the possible actions/alternatives? >>> I think this was already mentioned: add a BC layer to ext/mysqli so >>> that the "new" extension supports the old mysql_* functions. This would >>> rid us off the old ext/mysql code without breaking code that relies on >>> it. >> ... while such a wrapper has about the same amount of code as the >> classic mysql extension (... which is in most parts a simple wrapper >> over library functions...) Or in other words: Such a wrapper doesn't >> have real benefits. > > And any wrapper which is there by default won't change anything. People will > continue to use the old API. You need to move the masses or create facts by > removing ext/mysql. The latter is quite crazy considering how popular > ext/mysql is. Its popularity is somewhat understandable: its old and the API > is very phpish in a classical non PJAVA sense. > > One of the few things that could be done is adding a note to each and every > ext/mysql docs page stating that one shall use ext/mysqli instead and give > examples how to do it.
well couldnt the compat layer be written in PHP? i think this will send a fairly clear message. finally IIRC there was a mysql->mysqli conversion script that could be prominently placed in the docs. and of course we can add deprecation notices. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
