A while back there was a discussion on the Development list about just how much we can get away with in terms of pushing for new versions of software. The general consensus was "follow the market", which means that Drupal 6 will require MySQL 4.1 but will still be stuck with PHP 4.3. However, the question of PHP_Compat came up and received positive feedback.
PHP_Compat, for those not familiar with it, is a PEAR library that provides user-space implementations of functions that were introduced in later versions of PHP. It covers most of the functions that were introduced post-PHP 4.0.0 that can be implemented without relying on language/engine features that are by nature not backportable. Like the rest of PEAR it is released under the GPL-incompatible PHP License, but chx spoke to the lead developer for it and he was more than happy to let us use it in Drupal anyway on the grounds that there's frequently only one good way to implement some of these functions anyway, and to be neighborly. See: http://lists.drupal.org/pipermail/development/2006-November/020834.html
The attached patch is just one line, to include a new compat.inc file (which will be attached to a following comment in a moment). I wasn't certain what boostrap step was appropriate for it. I leave that decision to Dries et al.
compat.inc is a direct copy and paste of the constants and functions from PHP_Compat that are missing from PHP 4.3. They are all wrapped in a function_exists() call, just as in PHP_Compat. The loadFunction() method, however, is not included. It is just a single file with a lot of if(! function_exists()) calls. The loadFunction() mechanism is, in my experience, extremely slow and pointless.
What does this mean? It means that developers, both core and contrib, can make use of numerous functions from the PHP 5 era in Drupal while still maintaining compatibility with PHP 4.3. If Drupal is run on a PHP 5 box, the function_exists() calls will all skip the code and the total impact is negligible. On a PHP 4.x box the user-space versions will be loaded and made available. Developers needn't care which is which. They will run faster on a PHP 5 system, since they would then be implemented in C code in the engine rather than PHP code, but that's just one more reason people should choose hosts that support PHP 5. :-)
Why core, instead of a contrib module? While a contrib module could provide these functions in almost the exact same way, and a Drupal 5-targeted version is not unreasonable, a contrib module can't be used by core. :-) By putting this file in core, it makes, for instance, a dozen extra array handling functions available to developers working on the menu system, FAPI, and so forth. Given how heavily Drupal relies on arrays, that's a major win. This patch doesn't implement any changes to those systems at this point, nor do I believe it should. Figuring out how to leverage all of these toys to make FAPI++ or the new menu system faster/cleaner/cooler I leave to those who are already up to their ears in those systems.
Submitted for your approval...
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | compat.txt | 64.64 KB | Crell |
| php_compat.patch | 656 bytes | Crell |
Comments
Comment #1
Crell commentedAnd the compat file. Rename it to compat.inc and place it in the includes/ directory. (.inc is no longer a legal attachment type, bah!)
Comment #2
dries commentedI'm not a big fan of including these functions. We can include them one-by-one when we really need them. So far we managed to survive without these.
Comment #3
Crell commentedDur. You couldn't have nixed the idea when we were discussing it on the dev list?
For what definition of "really need them"? These are all standard functions available in later versions of PHP. Sure you can write code without them, but you could say the same about 2/3 of the PHP API by just reimplementing all of the array_ functions yourself as needed. Of course, that's a huge waste of time and code and speed. The idea here is to let us "have our cake and eat it too" with regard to some newer features without breaking compatibility with PHP 4.3.
The other option (excluding "do nothing", which based on the thread on the dev list I don't think is a good idea) is to have developers drop them in in bits and pieces throughout contrib modules. That would only result in more code, redundant code, and potentially breaking code if any one of them forgets the function_exists() call. Of course, there's also the license issue, which is probably why no one has done so to date but we do have permission now to offer all of Drupal some newer features.
If you want to offer only a subset of these functions I'm open to that, but I worry about it becoming a bikeshed problem. The functions I'd use regularly are not the ones chx would use regularly or you would use regularly.
Comment #4
Crell commented