PHP architect

As you’re probably aware, Phar is now a core extension in PHP 5.3. This is great news for Greg Beaver, the project lead; he has worked incredibly hard to make the extension do all that could possibly be asked of it, and more. Marcus Borger and myself also work on the extension, but we’ve been left blinking at the speed of development more than once. At the time of writing, Greg had just added OpenSSL signing support to Phar, which means that the only thing left on the immediate TODO is performance optimization.
Oh, and forward compatibility.
Now optimization is definitely more Greg’s kind of thing than mine, and Marcus doesn’t have much spare time these days, so I took it on myself to focus on that other thing. I went to look at PHP 6.
The good news is that from now, all phars created using PHP 5.2.1 and up should run under PHP 6 and vice versa. The structure’s unchanged. Sing hallelujah.
The bad news is that a phar with a default stub won’t run under versions of PHP prior to PHP 5.2.1, whereas we had PHP 5.1 support this time last week. Blame: b and the binary cast. The default stub calls unpack(), you see, and PHP 6 needs to be told that the second argument to unpack() is a binary string and not a Unicode string. The only ways we have of telling PHP 6 this will throw a parse error in PHP 5.2.0 and under. There’s no way to have both backward compatibility and forward compatibility: we have to choose.
I approached Andrei Zmievski and asked why we couldn’t simply have a fallback implicit conversion from Unicode to binary where the context is known, i.e. in built-in PHP functions that require binary strings. He explained that there’s no way to be certain of the intended encoding. I argued. After all, the user has control over the encoding through various INI directives and/or through the actual encoding of the physical script; we just needed to know which of those values would be used for implicit conversion. Andrei reiterated that implicit conversion is generally a Bad Thing, due to the lack of certainty.
Muttering ’new INI directive’ under my breath, I’m still failing to see why an implicit conversion in that context couldn’t be allowed and accompanied by an E_STRICT or even an E_DEPRECATED advisory message, just to make BC more possible. We never expected to support PHP 4, and thankfully there aren’t many PHP 5.0 users out there, but PHP 5.1 is relatively popular and it’s pretty hard to swallow losing userland compatibility with it from PHP 5.2.1 up.
I’ll be interested to see what Stefan Priebsch has to say about forward compatibility
in his migration series, but unfortunately we all have to wait another month to read his take on that. It’s still interesting, from the perspective of PHP 5.3.0-dev, to see just how far we’ve come since PHP 4