Hello Chris,
Chris Stockton wrote:
> I am not sure I am following you here Angel, are you confusing
> backwards and forward compatibility?
It can probably be termed both ways, depending on which version you stay.
I'm refering to the ability of a php file to work in both version 5.4
and 5.5 yet
take advantage of a 5.5 feature if available.
> I wouldn't expect a feature to ever work forward compatibly.
> I.E. Can't use traits in php 4 and can't
> play a blu ray disc in a dvd player.
The introduction of a new function is a good example of compatibility. The
code can easily detect and fall back
function getRandomNumber() {
if (function_exists('rand'))
return rand();
else
return 4; // chosen by fair dice roll, guaranteed to be random
}
or even show a graceful error message (instead of a cryptic php error):
if ( version_compare(PHP_VERSION, '5.4', '<') )
die("This program requires the awesome 5.4 version of PHP");
class Foo {
use Bar;
...
}
The later one is an example of what would *not* work, since even though
the developer tried to show a clear error to the end user unexpectedly
installing in an older php version than supported, he would get
"PHP Parse error: syntax error, unexpected T_USE, expecting T_FUNCTION"
which in no way leads them to the "You need to update PHP" conclusion.
> The goal here is that if you have
> a large code base which has a hand rolled include_code function
> already, your change is backwards compatible with that code base. Same
> to be said for any constants, which is why I recommended using the
> reserved PHP_* space.
The goal is to allow use of the new characteristics without having to drop
support for old PHP versions, which is something typically done quite
conservately.
In this case, it would even be possible to make a userland include_code on
old versions by falling back to an eval(). Not as good, but the codebase
is still
supporting the old PHP engines (back to X version).