Support React v0.3 and PHP 5.3

[clue]

No description provided.

[igorw]

👎 BC hacks like this are a major pain to maintain

[jmikola]

@igorw: What about merging this to a 0.3 branch just to make the tag? I'd swap in 0.3.* for the other react library deps in composer.json.

As for the master branch, we could either leave as-is or merge 0.3 in and then immediately revert this commit (just so master appears to be fully up-to-date with "older" branch commits going forward).

[cboden]

I'm +1 to putting this in a 0.3 branch and tag. I'm all for pushing forward with using new language features and I agree maintenance is a huge PITA. However not everyone has the luxury of using the latest and greatest. This change is minimal and since @clue has already done the work I don't see any harm in letting people stuck on 5.3 have ChildProcess.

[jmikola]

@clue: I took a look at PHPUnit_Util_PHP_Default, which is used to launch tests in their own processes. It utilizes SebastianBergmann\Environment\Runtime to do the PHP binary detection, which is much more robust for varying platforms and interpreters (e.g. older PHP versions, HHVM).

Can you replace this cmd() function with getPhpBinary() and then conditionally use SebastianBergmann\Environment\Runtime if the class exists (it will for more recent PHPUnit versions). Otherwise, we can fall back to PHP_BINARY if defined and then finally php.

In the existing test functions, you can leave the $cmd = ... lines as-is, and just replace PHP_BINARY with $this->getPhpBinary().

[jmikola]

@clue: Were you going to force-push the branch you showed me yesterday to update this PR?

[clue]

@jmikola, I've just pushed the updated commits. For now, I've decided against amending the existing commits in order to better highlight the development. I'll squash the changes if you feel this is ready to get merged.

this will be merged to a 0.3 branch […]

I understand your reluctance in adding BC hacks and understand you consider the $that = $this assignment being one such hack. I've deliberately tried to keep the changes in this PR to a minimum to highlight that tossing compatibility with PHP 5.3 is an arbitrary (politic) decision not imposed by technical limitations. Assuming we were to find a way that avoids hackery but involves a slightly bigger changeset, would this still land in a dedicated and deprecated branch that gets overwritten immediately after?

My motivation for filing this PR is BC with PHP 5.3 so that (any version of) this project can be used with PHP 5.3. As such, dropping support in future versions again isn't really a major concern admittedly. I'm just trying to understand the rationale in intentionally limiting BC in the future.

[jmikola]

@clue: Please see 36f4b29 for my merge commit of this PR into 0.3. I've yet to tag anything, but if it looks good, I'll create the v0.3.0 tag and then merge 0.3 forward to master and add the necessary reverts (bumping PHP compatibility to 5.4+ and updating the 0.3.* sister library dependencies to 0.4.*).

@cboden: I noticed that all of the React libs have a master branch alias of 0.5.x-dev. I suppose we can do without a 0.4 branch (or create one from the v0.4.0 tag if a patch release is ever necessary down the line)?