Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99393
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain tekwire.net does not designate 212.27.42.4 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>
Message-ID: <5e8464ca-8fa1-ad0c-c296-36ed1b6bd2a3@tekwire.net>
Date: Tue, 6 Jun 2017 12:27:45 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.20.1706061012130.2857@singlemalt.home.derickrethans.nl>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: fr
Subject: Re: [PHP-DEV] Proposing inclusion of PCS in the 7.2 core distribution
From: francois@tekwire.net (=?UTF-8?Q?Fran=c3=a7ois_Laupretre?=)

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