On Mon, 23 Mar 2020 at 16:04, Mike Schinkel <m...@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]
