> On Oct 10, 2022, at 6:20 PM, David Gebler <davidgeb...@gmail.com> wrote: > > My two cents... > > Why can't "common users" install a PECL extension? It's not a difficult, > obscure or undocumented process.
A lot of developers (most?) who build PHP applications run them in shared-hosted or managed hosted servers where are never given the option to install a PECL extension. In the rare cases they can install PECL many of those PHP developers would not have the skills to do it or the requisite permissions on the server; I certainly did not for the first ~10 years of working with PHP. I do now, but ironically because I have mostly moved away from programming in PHP to do more DevOps work. Further, when working in multiple environments having to set up each server to have all the same PECL installations can be just too much hurdle so that developers won't even try, especially when working in managed environments. [1] https://stackoverflow.com/a/12750694/102699 > I can accept the reasoning > >> Apply a PECL strategy to try experimental features might not be the > convenient way always, for example, if we create a new ... sensitive ini > setting that affects the behavior of PHP somehow... OR ... what about a new > sensitive funtion in a "core extension" like JSON? > > But why would the answer in those cases not be "compile the PHP fork/branch > with the experimental feature", rather than find a way to flag the engine > to switch arbitrary new features on or off, complete with all the > complications in the primary source code that would cause? We are, after > all, talking about features which by definition should not be relied upon > for any production use. > > Or we're talking about features which are stable and valuable enough to > have passed an RFC process, but then what's gained from an experimental > designation? Why couldn't they just be included in a preview/beta/RC > version which anyone could decide to run or not? It does not seem reasonable that the bar to include a feature as experimental should be the same bar as currently exists for forever features. Opinions expressed on the list typically fall into one of three categories: 1.) Please, please yes! 2.) No way whatsoever! or 3.) I am not convinced... Generally it seems that unless 2/3rd are in the #1 category an RFC fails to pass, even if after evaluating in the wild the people in group #3 might come to see a lot of value in it and some in #2 might even change their mind. In those cases PHP suffers. If there were an RFC for Experimental Use then the people on the fence could choose to allow it to see how it plays out in real-world userland cases, and a few people against it might be convinced to allow people to evaluate it, and then later make a decision on a "Forever RFC." --------------- Also, the comments along the lines of "Well, this could quickly get out of hand" presume that the people voting for experimental use won't take that into consideration and vote against things if it seems like things are in-fact getting out of hand. But they will take that into consideration just a as the take other concerns into consideration now, and thus only the better ideas will be likely to make it through to experimental status. --------------- One more thing on this topic. PHP could ALSO allow experimental features to be written in PHP, and ship those experimental features with PHP so that code would always be available, at least when experimental features are turned on, and without having to include said code. The benefit there would be people could more quickly implement an experimental feature to see how it might work in the wild before going to all the effort to implement in C in PHP's core code, for things that can be implemented in PHP. -Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
