> 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. > Having new extension (outside of language feature) directly added > to php-src is IMHO a terrible way. > > Having "dead" extensions in php-src is a real problem > (the ones nobody take care of anymore, only adapted for new version) That is not the argument that was made. The argument is that a developer cannot: 1. Depend on a PECL extension to exist, and 2. Cannot even use (most) PECL extensions when they use managed hosting. So the PHP extensions mechanism is in large part the problem here. If PECL extensions were 100% safe and could be loaded by userland using only PHP code then most of the pressure to see functionality is core could be relieved. That's why I floated the idea of supporting WASM in core. > But I'm probably the only one who think much more extensions > should be removed from php-src and maintained outside, in pecl. Let me guess. You or your team manages your PHP servers, you don't use managed hosting? -Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
