Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99397
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain rhsoft.net designates 91.118.73.15 as permitted sender)
To: internals@lists.php.net
References: <5313411f-40b4-58c6-83a8-7e813526f2a7@tekwire.net>
 <12948b4b-bd2d-b88e-80a0-f70ba2d49657@fedoraproject.org>
 <alpine.DEB.2.20.1706061012130.2857@singlemalt.home.derickrethans.nl>
 <5e8464ca-8fa1-ad0c-c296-36ed1b6bd2a3@tekwire.net>
 <05d8f04a-4fad-fbee-4bc5-bf85f282212c@rhsoft.net>
 <df2de4b4-ff11-cfde-88af-c3cef7220150@tekwire.net>
Message-ID: <1de8757c-6f4e-33d0-e333-9c1dd6f66e3a@rhsoft.net>
Date: Tue, 6 Jun 2017 13:27:16 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.1.0
MIME-Version: 1.0
In-Reply-To: <df2de4b4-ff11-cfde-88af-c3cef7220150@tekwire.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: de-CH
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Proposing inclusion of PCS in the 7.2 core distribution
From: lists@rhsoft.net ("lists@rhsoft.net")



Am 06.06.2017 um 13:06 schrieb François Laupretre:
> Le 06/06/2017 à 12:33, lists@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.

looking at the code quality (style, readability, robustness, 
error-handling) of 99% of php userland code out there - which is 
horrible to say it nice -  even if all that is true i still doubt that 
it improves quality in the long term, sometimes it's better working 
things are not maintained then badly maintained