Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109231
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <2d2757f9-7303-3f57-6318-68ebdc4a8097@php.net>
Date: Mon, 23 Mar 2020 11:01:23 -0400
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <9711E280-743A-4EBE-9E32-9D21A2E5FFC7@newclarity.net>
References: <A1C95241-282A-4BF7-AEAC-93CAB56811E4@newclarity.net>
 <2d2757f9-7303-3f57-6318-68ebdc4a8097@php.net>
To: Remi Collet <remi@php.net>
Subject: Re: [PHP-DEV] Are PECL modules preferable?
From: mike@newclarity.net (Mike Schinkel)

> On Mar 23, 2020, at 6:36 AM, Remi Collet <remi@php.net> wrote:
>=20
> Le 21/03/2020 =C3=A0 23:52, Mike Schinkel a =C3=A9crit :
>>> On Mar 21, 2020, at 5:59 PM, tyson andre <tysonandre775@hotmail.com> =
wrote:
>>> FROM: Re: [PHP-DEV] [RFC] is_literal()
>>>=20
>>> 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.
>>=20
>> Just wanted to address this comment which was made on another thread =
(I did not want to hijack that thread.)
>>=20
>> 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.
>=20
> Sorry, but PECL is the usual way for new extension
>=20
> - add to pecl
> - people start using it
> - if success add to php-src
>=20
> And later
>=20
> - 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.
>=20
> 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.=20=


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=