Bring the codebase up-to-date with php 5.3+ standards

[quinn]

I would like to bring our codebase framework up-to-date with php 5.3+ standards, specifically with class definitions, public/private method statements, magic functions, etc. Currently it works fine under php5, but I'd like to take the final step so it runs exceptionally on php5 and not at all on php4.

Goals

Identify new features introduced between php 5.0 and 5.3 that will:

• bring tangible benefit for our use (e.g., anything that brings a performance benefit, or improves error handling)
• make the codebase more future proof (e.g., migrating the current mysql_* function calls (which are to be depreciated in v6) with something else, or implement the required aspects of the new Object Model).

The code should run with no errors using 'E_STRICT' and 'E_ALL' error_reporting, and pass all the unit tests (run via codebase/test/run_tests.sh).

Requirements

1. Backwards compatibility with existing sites that use the codebase. This will make implementation of PDO slightly more tricky, but is possible.
2. Don't make modifications that require extensive testing. Currently the codebase is mature and very stable. I hope the changes we make won't' make it unstable.
3. We only implement what we can do in 10-15 hours.

[eli]

OK. This is just a preliminary sketch of what could be done. I'll do a bit more investigating around what changes will bring more efficiency, and post back. The PSR-0 suggestion would probably break backwards compatibility, so that one should probably be stricken. But I think it's worth considering, and there might be a way to do it that wouldn't break back-compat.

1. remove closing ?> from end of files.

2. replace mysql_* functions w/ PDO functions

3. add private, public, protected keywords to functions

4. replace getParam() function and _params array with object properties. Instead of $this->getParam('log_directory'), use $this->log_directory. -- I've included a benchmarking script that compares the 2 methods.

5. use PSR-0 autoloading. see: ​http://www.sitepoint.com/autoloading-and-the-psr-0-standard/ --this will be helpful in the future if we ever want the codebase to play nicely with other frameworks such as Symfony2

6. allow disabling of error logging. add a boolean $debug and wrap all $this->logMsg calls in "if($this->debug) " statements. Ideally we should be able to turn off debugging completely on a production site.

7. defer error logging until scripts are finished executing. In other words, write to the error log all at once, rather than multiple times during execution.

8. remove returning value of "new Class()" by reference. run_tests.sh returns:

PHP Deprecated: Assigning the return value of new by reference is deprecated in /opt/codebase/tests/VersionTest.php on line 49. --- So anything like $var &= new Class();

[eli]

One of the new and shiny features in 5.3 is the use of lambda functions and closures. I'm not sure where these might be applied in the codebase, but there may be spots where these could be applied.

Another page worth looing at is new classes introduced in 5.3: ​http://php.net/manual/en/migration53.classes.php

[quinn]

Replying to eli:

One of the new and shiny features in 5.3 is the use of lambda functions and closures. I'm not sure where these might be applied in the codebase, but there may be spots where these could be applied.

Another page worth looing at is new classes introduced in 5.3: ​http://php.net/manual/en/migration53.classes.php

Perhaps in the case where a function was defined only to be passed as a callable argument, e.g., to array_map(). But there isn't any benefit to rewriting this code. Leave as is.

[quinn]

Oh rats; this comment didn't get posted last night (POST error):

Eli

I've reviewed your suggestions and the PHP docs, and enumerated some tasks in the "Codebase PHP updates" spreadsheet (I shared it with your gmail address). Please review, amend if I missed anything, and let me know if you have any questions.

The next step is to define a test suite, what it means to maintain "backwards compatibility", and define a methodology for attacking these tasks.

I'll be off the computer Thurs-Sun, so if you have time to chat tonight (after 7 or 8pm) we can discuss this to get you started.

---

Ok, so we didn't connect last night. I'll just give you a couple guidelines to get started:

• follow our ​coding standards (4 spaces per tab)
• do one task, then comit your work (svn ci -m "description of work") so we can easily review and roll back changes if needed.
• If in doubt about how to do something, or if it might break backwards computability, leave it for us to discuss next week.
• or go on a weekend off the computer like me! anyways, enjoy.

Q

[eli]

PHP Mess Detector Ouput

[eli]

PHP CodeSniffer? Output on ACL.inc.php

[eli]

Quinn,

I've run both pmd (php mess detector) and phpcs (PHP_CodeSniffer) and am uploading their respective outputs here. I ran phpcs on just one file, ACL.inc.php, rather than the entire codebase. Figuring that you would review the output and decide on what's important and what's not.

-Eli