PHP Classes

Design and decision

Recommend this page to a friend!

      PHP Classes blog  >  The Plot to Kill PHP ...  >  All threads  >  Design and decision  >  (Un) Subscribe thread alerts  
Subject:Design and decision
Summary:Lets think of the underlying problem and and the alternatives
Author:Grzegorz Kaczorek
Date:2011-07-15 12:20:53
Update:2011-07-16 05:03:13

  1. Design and decision   Reply   Report abuse  
Grzegorz Kaczorek - 2011-07-15 15:44:32
First of - in a site for PHP professionals (and aspiring ones) one thing must be noted - any codebase that would require changes in more than one class file for this sort of change is poorly designed and written.

There is quite a limited stack of functions that a database connector can do, and using specific extension functions on a whole codebase is just bad practice. It was bad practice in ye olden days of PHP4 - now it's just silly.

If you've written it - learn from your mistakes and don't make them in the future.
If you've hired someone that wrote it - next time hire someone better.
If your software is x-teen tear old - don't expect the world the world to sit still just because you will - when you buy a car, you don't expect that it will always be shiny and new (unless you take regular and expensive care of it that is).

The situation with 'var' was a substancial syntax change which meant that anyone writing for PHP4 couldn't have known that he should have written 'public' instead. A PHP5 migration would mean that whatever your coding skill and design was - you would have to change your whole codebase - not just one file (if you know what you're doing) as mentioned earlier.

Second - Manuel - what would you suggest the PHP team do?

Beyond the option that they chose, they would two others:
- keep the mysql extension until the end of time
- drop it violently without throwing E_STRICT in earlier versions
- (this isn't really a choice, but rather a deference of choice) wait some time and decide later

The second one is obviously not the one anyone could prefer (or is it?) so let's consider the first one.

mysql is the oldest MySQL extension - it looks as if it was written in times before the OOP paradigm was invented. It encourages bad coding practices, leads to security risks and has three (three! and that's only in the specific database engine field) superior alternatives. Why on earth should anyone care to keep it.

"If it's not broken - leave it alone" - I wholehearthedly agree. Leave it alone. And that INCLUDES the whole enviroment. From the kernel, DB, HTTP and parser - nothing should change. What's that you say? You need the latest security/bug fixes? Well you know what I call software that has security issues and bugs? I call it broken.

  2. Re: Design and decision   Reply   Report abuse  
Manuel Lemos - 2011-07-16 05:03:13 - In reply to message 1 from Grzegorz Kaczorek
There is a better solution. Add wrapper functions to the MySQLi extension that provide the same functions as mysql. This way there would only be one MySQL extension and people with legacy code relying on the mysql extension would not be left out in the cold.