Re: Are PECL modules preferable?

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." -Mike > On Mar 23, 2020, at 1:25 PM, Rowan Tommins <rowan.collins@gmail.com> wrote: > > On Mon, 23 Mar 2020 at 16:04, Mike Schinkel <mike@newclarity.net> wrote: > >> >> The original point of this thread was to make the case that PECL >> extensions are _not_ a viable alternative to including features in core. >> >> It does not matter if a host installs _some_ unbundled PECL extensions. >> What matters is that the userland developer _cannot_choose_ to use a PECL >> extension if the managed host does not _already_ have it installed. >> > > > My point is that they cannot choose which "bundled" extensions they use > either. That choice is entirely up to the managed host. > > > >> You also brought up some orthogonal facts about extensions being bundled >> vs. unbundled extensions and how a managed host might choose to install >> some unbundled extensions. But while your points are true, there were >> irrelevant to the problems identified by this thread so mentioning them in >> essence hijacked this thread and refocused it on concerns unrelated to the >> original concern of this thread. >> > > > They are neither orthogonal nor irrelevant, they are directly addressing > the question "does bundling an extension give an advantage over having it > in PECL?" > > > >> Once a managed host has a working platform they are loath to change it >> because something might break and create downtime for their customers that >> is potentially devastating for their business. >> > > > This is true of bundled extensions as well as PECL ones. > > > >> Thus managed hosts rarely add things to their platform unless they need >> them to support their platform (like redis or new relic) or there is >> OVERWHELMING DEMAND in userland for adding them. >> > > > This is true of bundled extensions as well as PECL ones. > > > >> So it is_literal() came out in a PECL extension and I went to a managed >> host and asked to use it they would politely tell me "sorry, we don't >> support that." >> > > > This could well be true of bundled extensions as well as PECL ones. > > > >> Distros are not going to add potentially buggy extensions to their >> distros. They are going to wait until an extension has had plenty of time >> to mature _and_ that there is a significant number of developers that want >> the functionality. >> > > > This is true of bundled extensions as well as PECL ones. > > > >>> Ultimately, the barrier to having *any* functionality included on a >> managed >>> platform like that is convincing the host that it will make their >> platform >>> better. >> >> That is a false assertion. Managed hosts will upgrade to the latest >> version of PHP once the initial bugs are worked out. Full stop. >> > > > Upgrading to the latest version of PHP does not automatically give you all > bundled extensions. > > This is the key point I'm trying to get across here. Every extension > "bundled with" PHP, with a tiny set of exceptions, is optional. > > > The only way to get around that is to make the feature *mandatory*, that is: > > * part of the absolute core of the language grammar or engine > * part of an existing mandatory extension like ext/standard or ext/spl > * a new extension which is not just bundled but which cannot be disabled in > the build configuration > > There are a few cases where that's a reasonable thing to do, but most of > the time when people are discussing "PECL vs core", they are talking about > a new extension, which would be optional anyway. > > >> Yes, when an extension is missing developers have to deal with it. Which > is exactly the point. > > Exactly what point? The example I gave was ext/curl, which doesn't require > anything from PECL, it's just optional in the build. > > If you're saying we should move away from the language being modular, and > having optional extensions, then we can discuss that. But that's a very > different discussion from "PECL vs core". > > > Regards, > -- > Rowan Tommins > [IMSoP]