On Mon, 2020-03-23 at 11:01 -0400, Mike Schinkel wrote: > > On Mar 23, 2020, at 6:36 AM, Remi Collet <r...@php.net> wrote: > > > > Le 21/03/2020 à 23:52, Mike Schinkel a écrit : > > > > On Mar 21, 2020, at 5:59 PM, tyson andre < > > > > tysonandre...@hotmail.com> wrote: > > > > FROM: Re: [PHP-DEV] [RFC] is_literal() > > > > > > > > And if it can be implemented as a PECL module, that would be > > > > more preferable to me than a core module of php. > > > > If it was in core, having to support that feature may limit > > > > optimizations or implementation changes that could be done in > > > > the future. > > > > > > Just wanted to address this comment which was made on another > > > thread (I did not want to hijack that thread.) > > > > > > A large number of PHP users have no control over the platform > > > they run on, so the option to use PECL modules is a non-starter > > > for them. > > > > Sorry, but PECL is the usual way for new extension > > > > - add to pecl > > - people start using it > > - if success add to php-src > > > > And later > > > > - move to pecl extensions removed from php-src > > Yes, it is the usual way. Which from my perspective is flawed > because it means that a large population of PHP developers can never > use those extensions. >
Bundling doesn't make much of a difference. Only force-enable (like we do with ext/standard, date, SPL and few others do) does. Most users use distribution-provided packages of PHP. For those Core or PECL matters little. Distributors package extensions in seperate packages, even if we consider them core. At the same time they ship pecl extensions. Thus whether one wants gd or some pecl extension is the same complexity. For somebody building PHP themselves compiling a PECL extension isn't too difficult either. For Windows pecl produces builds where we can, while users have to install by hand. Awarness however is different ... johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
