Re: Are PECL modules preferable?

From: Date: Mon, 23 Mar 2020 18:11:02 +0000
Subject: Re: Are PECL modules preferable?
References: 1 2 3 4 5 6 7 8  Groups: php.internals 
Request: Send a blank email to internals+get-109243@lists.php.net to get a copy of this message
> On Mar 23, 2020, at 13:09, Mike Schinkel <mike@newclarity.net> wrote: > >> On Mar 23, 2020, at 1:51 PM, Ben Ramsey <ben@benramsey.com> wrote: >> >>> On Mar 23, 2020, at 12:34, Mike Schinkel <mike@newclarity.net> wrote: >>> >>> Rowan, >>> >>> Based on your responses now I am not at all sure what you were driving at. >>> >>> I think you are making detail points because of nuances of PECL and bundled vs. >>> unbundled etc, while I was trying to make a higher level case. >>> >>> So let me restate the thesis: >>> >>> "When discussing a potential new feature suggesting that it be implemented in a >>> way that it might not actually be available (via PECL, unbundled, disabled, whatever) is not a >>> viable alternative for many PHP developers unless integral to the feature is a need to make it >>> optional.” >> >> >> I think Rowan is making the point that *most* of the features found in the core PHP >> distribution are *optional*. Distributions and hosts are choosing to enable them. There are very few >> things in the core distribution that cannot be disabled at build time. >> >> I’ve run into this numerous times in my userland OSS libraries. It came up recently with >> the ctype functions. Someone’s host had these disabled, for whatever reason, so I had to use a >> polyfill library to provide the functionality, for those cases. > > Which makes an even stronger case for why a userland accessible extension mechanism is needed. > > Did you see my reply to you about the various options for userland extensibility with the (IMO) > most promising one being adding support for WASM to PHP core? Yes, I did. I don’t know enough about WASM right now to comment on it. Cheers, Ben

Attachment: [application/pgp-signature] Message signed with OpenPGP signature.asc
« previous php.internals (#109243) next »