Le 06/06/2017 à 12:33, li...@rhsoft.net a écrit :


Am 06.06.2017 um 12:27 schrieb François Laupretre:
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.

but what is the difference? just because you re-write some code in a different programming language don't grow maintainers for the future of that code

Wrong. Moving code from C to PHP reduces the code size, improves readability, and dramatically increases the count of potential maintainers. How many times did we get messages on the list such as 'I would love improving/maintaining the xxx extension but I cannot program in C' ?

Let's take the 'phar' extension as an example. The source code is about 18,000 lines of C. After a quick look, I consider that more than 90 % of this code can be rewritten in PHP without loosing ANY performance (because this code is used during package creation only). Prior C to PHP conversions show that the resulting PHP line count is about 10 % of the original. So, we can transform 18,000 lines of very complex C code into about 1,500 lines of PHP and probably less than 1,000 remaining lines of C. From a maintainability POV, this makes the situation very different. After such an operation, phar can attract active maintainers and evolve. If it remains as it is now, experience shows that it is frozen for a very long time.

Regards

François

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to