Hi,
Le 06/06/2017 à 11:13, Derick Rethans a écrit :
On Tue, 6 Jun 2017, Remi Collet wrote:
Sorry, but I don't like the idea of having PHP code bundled in C
extension.
Have low-level part written in C, and user-land part in PHP is indeed
a good way (e.g. mondodb, phpiredis + phredis...), but having the PHP
library distributed via composer or any other way is enough.
P.S. IIRC couchbase have tried this way, and revert it
We did it as well, in the early early days. It wasn't great and reverted
that too. I also believe PHP code should be distributed through
composer, and that is much easier to upgrade, as well as allow for
multiple versions running on the same server.
I agree that, in the case of 3rd-party code, like mongodb, splitting the
C code and the PHP code brings benefits. The biggest one being that you
can release the PHP package more often than the C extension (at the
expense of maintaining compatibility between both packages). This also
takes place in the context of an application, whose dependencies are
managed by composer.
What I am proposing here is very different, as the main objective is to
dramatically reduce the line count of the core source, without
significant performance loss. If we had an army of C developers
maintaining every core extension, maybe we wouldn't need that, but we
don't (we even have fewer and fewer). What we have instead is thousands
of lines of C code without any active maintainer. 'phar' is an example
we talked about recently, but there are many others. Converting some of
this code to PHP without loosing performance would improve the
situation, IMO. So, while I agree that 3rd-party extensions may have
very good reasons to maintain both an extension and a PHP package,
opposing this for core extensions is very different.
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
