Comments for the post http://yanntx.info/2015/02/php-versions-and-modernizing-legacy-applications/

comments.md

Hey,

Nice write up. If the applications can work on 5.3, there will not be much problems to upgrade to the latest versions of PHP.

May be all library owners should consider upgrading the php versions of libraries and force people to update the apps to latest versions. Then there is a question of how to overcome the legacy applications. We should provide an alternative library which works with the latest version.

Eg : we have password_ functions for less than 5.5. Like that we should replace other functions which can make use of the 5.5 functionality .

Thoughts ?

Sounds like you're advocating for what JS-land calls polyfills. In their case the runtime is a browser. In our case it's the Zend runtime. For core functions that are available in newer versions of the language as part of core, I fully support this. Google has done something similar with new OS APIs via Play Services, and the result is that their OS fragmentation (which is still pretty bad) isn't that big of a deal.

I think that it makes sense to, when possible, make a progression of:

1. User-mode library (probably pulled in via Composer)
2. C extension based on the current PHP version
3. Core feature (optional)

for functions, and if (3) (or maybe (2)) exists now for a given function that isn't available in older releases, there's a good reason to build (1).

An added bonus of this is that you can turn (1) into an HHVM extension with a trivial level of effort.

Now, you can't backport traits to 5.3, nor can you get reasonable performance for some userland code, vs. doing things in C. But performance, security and language features should be enough to pull people onto later versions.

Heck, you could go so far as to say that some libraries that depend on 5.5+ functions (not language features) could have a guide for manually pulling in the necessary libs to make them work on 5.4. The lib dev shouldn't spend much time on this, and in my opinion it's okay if the end user of the lib does spend a bit more time to get things working (e.g. overriding composer.json's minimum PHP version requirement). But it is a possibility.

I think I'll write a post on the userland -> extension -> core process later. THanks for the comment!

Hey @iansltx ,

Just wanted to comment if we are not missing each other. I wasn't saying to make use of something like https://github.com/igorw/galapagos . Trait already supported ( igorw/galapagos#6 ) .

What I was trying to express was many of the users don't move to latest versions because some of the functions in 5.2 may be deprecated in 5.3 and later being removed. As an eg: http://php.net/manual/en/function.ereg-replace.php this is a simple function which can be build with http://php.net/manual/en/function.preg-replace.php

if (! function_exists('ereg_replace')) {
    function ereg_replace ( string $pattern , string $replacement , string $string ) {
       // implement
    }
}

There are many other functions probably cannot be addressed properly like this. So if there is a library which can provide the functionality probably the transmission can be much easier and they could eventually update the code.

Fair point. So there's a bit of a need for "reverse polyfills" in some codebases.

Question is where the biggest use of deprecated/removed functions is. My bet is actually on mysql_*