Recommend this page to a friend! |
PHP Classes blog | > | The Plot to Kill PHP ... | > | All threads | > | Users should be encouraged to adopt... | > | (Un) Subscribe thread alerts |
|
CJ - 2011-07-15 20:46:00
Considering Philip's email began with "This is not a proposal to add errors or remove this popular extension", it is trollish to use words like "plot" and "kill" in commenting on his post.
This is merely an attempt to document the current opinion of the core community about the very old "mysql" extension. He is trying to put into place an action plan for going forward and should be commended for forethought. The old "mysql" extension has many weaknesses, including security issues that should greatly concern any user (for more discussion see the PHP internals mail list). PHP application developers should be encouraged from their first interactions with the language to use a better API, namely the "mysqli" extension. There is a confusing plethora of extensions that can connect to MySQL. By de-emphasizing the old "mysql" extension in the PHP documentation and promoting the "mysqli" extension, this confusion can be reduced. This will ease the adoption of PHP. I invite PHPClasses to adopt a policy rejecting any MySQL-database related code submissions that don't support the "mysqli" extension or PDO_MYSQL driver for PDO. Chris -- mail: christopher.jones@oracle.com twitter: @ghrd
Manuel Lemos - 2011-07-16 08:36:54 - In reply to message 1 from CJ
I am afraid you are ignoring a key phrase in the original message from Philip that states:
"Not adding E_DEPRECATED errors in 5.4, but revisit for 5.5/6.0" As I mentioned in another thread, this reads: "We are not proposing to deprecate it in PHP 5.4, but we will consider proposing to deprecate it in PHP 5.5 or later" What comes after deprecation is death, which could be removal from the PHP main source tree and eventual dispatching to Siberia (AKA PECL). As for security issues, being vague is not helpful to anybody here. If the mysql extension has security issues, regardless of how security aware are the PHP developers, we certainly would like to know. Not being explicit about what are such security issues, sounds like a scare tactic for coerce people to change their code without letting them judge for themselves if they really need to change their code. As for refusing classes that use the old mysql extension, forget about it. This is a democratic site. Everybody has equal right to submit classes that do whatever they find useful. The only requirement of submissions is that the described functionality should be provided by classes. Even that requirement exists for a reason, which has to do with the benefits of encapsulating functionality in classes, like avoiding collisions of functions and variable names in the global name space which could occur when packages of different origins are used in the same script. So, the site does not refuse packages for any other reasons related with its code, except maybe for code explicitly meant to be used to violate laws. On the other hand, the site uses positive motivation methods. This means that instead of refusing packages that do not satisfy certain requirements, the site values and promotes packages that satisfy certain conditions. That is the case of the PHP Programming Innovation Award. There are tons of MySQL classes. The site does not need more generic MySQL classes. But instead of refusing more classes for the same purposes, it promotes classes that perform something innovative. phpclasses.org/award/innovation/ phpclasses.org/winners/ Any author that was nominated to the Innovation Award is entitled to earn prizes from sponsors and even get a free lifetime premium subscription, which among other things let the developers be features in the PHP professionals directory, and so have early access to posted PHP jobs or have direct contact with eventual companies willing to hire capable PHP professionals. phpclasses.org/professionals/ phpclasses.org/jobs/ This way the site motivates many capable developers to share valuable PHP components, without hurting the feelings of all those that send yet another class to access MySQL or do something else very common. So, if you have any idea to positively encourage developers to not submit more mysql classes because that may not be good for some reason, just let me know so we can talk about it. For instance, you mentioned security issues about using mysql extension. If you would like to write a clarifying post about it, I would gladly approve it for publication in the PHP Classes blog. Or maybe, if you would like to come to the Lately in PHP podcast to talk about those issues of using the old mysql extension, that can also be very interesting. Just let me know. |
info at phpclasses dot org
.