Does anyone have any thoughts on adding an official fork of runkit for php7.0+ to PECL? I maintain an unofficial fork of the PECL runkit extension on https://github.com/runkit7/runkit7, and want to add that fork (as an extension to with a small subset of runkit's functionality, for php 7.0) to PECL. I have experience maintaining other PECL extensions; I did a lot of the work required to finish porting igbinary to work in php 7.0+ (and to add new features/bug fixes since then) (https://github.com/igbinary/igbinary/commits/master). I have also contributed small patches/bug reports to some other related PECL extensions.
The last time the official runkit repo (or a branch) was updated was in 2015, and PHP 7 support for runkit has also been requested since 2015. There is no visible code on the official PECL github repo targeting PHP 7. I offered to help port it back then(https://github.com/zenovich/runkit/issues/87#issuecomment-138811228), but the maintainer refused to have anything to do with my fork. - I needed a subset of runkit (method manipulation and superglobals) for running my company's unit tests during the migration from php 5.6 to 7.0, and was able to implement php 7 support for that(https://github.com/runkit7/runkit7). Since then, I reintroduced support for more features and settings in php 7.0 and 7.1, and finished fixing the module's test failures (The subset and new params are documented at https://github.com/runkit7/runkit7/blob/master/runkit-api.php) - runkit7 works reliably in my company's unit tests. Open-source libraries for unit testing using runkit for function/method manipulation(https://github.com/runkit7/runkit7#examples) also work with this fork. Other reasons why I suggest a fork for php7: - PHP modules are easier to find on PECL, and have documentation on php.net Also, some users would have more confidence in a fork hosted on PECL than one hosted on github. - It's unclear how long it will take for the official PECL will have support for 7.0 or 7.1, or what the plans are to maintain runkit in future minor/major PHP releases (see https://github.com/zenovich/runkit/issues/87) - Some remaining functionality may take a really long time to fully implement. Creating an initial release of a fork with a small subset of core features, then slowly adding back other features would be faster than waiting for all of them to be implemented at once. Removing features from an existing extension to add them back later doesn't seem likely - The APIs for existing methods will be slightly different, now that methods have return types and constants have visibility. - A single project with #ifdefs and macros for each supported PHP minor version (from 5.0 to 7.1), and occasionally patch version would be hard (for new contributors or people who wish to submit patches) to understand. The significant differences between data structures and APIs in php 5 and php 7 would make this harder. - The lack of any official support(e.g. PECL repos) for php 7 in runkit has blocked some companies and projects from migrating to php 7, because of existing unit tests relying on it. - There's no complete replacement for runkit, e.g. uopz currently doesn't seem to work with xdebug, and uopz currently doesn't support manipulating magic methods (probably fixable). Multiple people commented on the github issue(https://github.com/zenovich/runkit/issues/87) that the lack of any official support for php 7.0 was blocking migrating their projects to php7, on that github issue. Outside the github issue, a different company(badoo) mentioned this as a blocker in their blog (thousands of unit tests relied on runkit). (Aside: they managed to work around it and instead created https://github.com/badoo/soft-mocks - see the below snippet from https://techblog.badoo.com/blog/2016/03/14/how-badoo-saved-one-million-dollars-switching-to-php7/ ) > (runkit turned out to be a big problem (for badoo) during the switch to PHP7 > because it didn’t support the new version. > We could have sponsored the development of a new version, but, looking at the > long-term perspective, this didn’t seem like the most reliable path to > pursue. ) P.S. runkit7 seems like a confusing pecl name, so I suggest "funkit" (as in "function", or "forked runkit"). A similar approach to apcu_bc is possible with a small amount of work (add a second extension depending on the fork to provide the old function names, for compatibility) -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
