A while ago, maybe two years or so at the time of writing, I began thinking PHP was dead. There were releases, and bugfixes, of course, but no noticeable innovation strategy. It's over the zenith, I believed, and that we'd see a slow but steady decline in projects. Time for rethinking technology at home and at work?
Today, it seems my thoughts were too early: The PHP group has since released PHP 5.4, 5.5 and the first alpha of 5.6. Each of them has brought a list of improvements not only on the detail level, but actually meaningful to adapting to nowaday's languages: Short array syntax, traits, method and array call chaining, full closure support, generators (yield), to name just a few. Also, they finally managed to rid themselves of the magic quotes crap. At the same time, each release has brought performance and memory usage improvements. And all that without compromising on stability: The number of critical bugs is perceivedly on an all-time low.
Also, the rise of Composer and its becoming a pseudo-standard has helped a lot on the interoperability of frameworks and components. Much more than centralized PEAR could ever achieve, Composer has fueled reusability in the PHP world. Of course, GitHub has contributed their fair part: Code is no longer sitting hidden in ugly 1999's CVS repositories packed away in .tar.gz files, but shines with a bright light and one-step-install instructions beautifully embedded in Markdown READMEs.
Looking at this makes PHP's future appear in a much brighter light. What next? Here are some thoughts:
Every PHP Framework, in the meantime, has some kind of type, method and member decoration method, usually within the target's api documentation comment. If PHP just supported adding unchecked key-values natively, this would be a great improvement and would make stuff work interchangeably.
class FixtureTests {
<<Test, Values([1, 2, 3])>>
function can_create($value) { ... }
}
$m= new ReflectionMethod('FixtureTests', 'can_create');
$m->hasAnnotation('Test'); // true
$m->getAnnotation('Test'); // null
$m->getAnnotation('Values'); // [1, 2, 3]
$m->hasAnnotations(); // true
$m->getAnnotations(); // ['Test' => null, 'Values' => [1, 2, 3]]This is the primary cause of the "white page" syndrome and the one single PHP un-feature straight from hell. Just throw an exception, really.
$result= $action->execute();
$result->toString(); // Fatals if execute returns NULLPHP's standard library is huge. And as inconsistent as it can get: strrev() vs. str_word_count(), and what's the argument order in in_array() again? Come on. A simple way out of this mess which would not break backwards compatibility beyond repair, clean up the library and at the same time make PHP code more attractive, would be to allow methods on strings, numbers and arrays. The way of having a "procedural" and an object-oriented API with is not new to PHP, the date and XML extensions both offer this dual approach, for example.
// Standardize verbs
$string->length(); // == strlen($string)
$array->length(); // == sizeof($array)
// Fold together alternative implementations
$string->replace('a', 'b') // == str_replace('a', 'b', $string)
$string->replace(['a' => 'b']) // == strtr($string, ['a' => 'b'])
// Use camel-case
$string->toLower();
$string->trimRight();
Some of these are also in https://wiki.php.net/ideas/php6