On Tue, Oct 11, 2022 at 12:05 AM David Rodrigues <david.pro...@gmail.com> wrote:
> The idea is that the experimental features are exclusively something that > the PHP team has voted for (approved) and that will be part of the language. > So they're not experimental features, they're accepted RFCs, maybe with a lower voting threshold. > Imagine a package under development (eg. Laravel 10) that is (supposing > that) intended to be released compatible with PHP 8.3 (supposing that it > already has experimental features). In this case, the Laravel team can > start using an experimental feature while developing Laravel 10, waiting > for the release of PHP 8.3. Once the PHP 8.3 release is finished, Laravel > 10 can just remove the experimental tags and release its new version fastly. > > The user, on condition that he is willing to use Laravel 10 (in > development) will make indirect use of experimental features. Then both the > Laravel team and these users will be able to provide feedback for these > features to the PHP team before the official release. > > Like json_validate(): assuming Laravel needs to check if a code is valid > JSON, but without processing its data for use. It could check if PHP >= > 8.3, so use experimental_json_validate(), else use previous PHP compatible > code. > This is what's bothering me. Either these "experimental" features have passed RFC and will be part of the language, as you've said above, or they're actually experimental i.e. not finalized and implementing behaviour and syntax which may be subject to change or even dropped entirely depending on the feedback cycle. In which case, they cannot be relied on by developers of vendor packages or their users in the manner you suggest. Using the trivial json_validate() example (although as others have said, a simple new function is probably a bad example), either this function will be part of PHP 8.3, with the exact behaviour, parameters and return type which is known and documented, or it's experimental and might change. If it's the former, the library can just check if PHP >= 8.3 and fall back to userland implementation / polyfill for earlier versions. This is just what we have now, where approved new features are part of a versioned release. If it's the latter, everyone touching the experimental version, directly or indirectly, may have to rip out and change code later which renders the work they've put in to use the experimental feature in their code pointless. And it's not just how these things may or may not be used by users of the language, it's how building out this system affects the clarity and maintainability of php-src, which is esoteric enough as it is. I can appreciate and support specific individual new, accepted features which may not be 100% stable having a toggle in the configuration, but I'm not convinced on the justification for a broader system of introducing unstable features which are toggled at the syntax level. On Tue, Oct 11, 2022 at 12:06 AM Mike Schinkel <m...@newclarity.net> wrote: > 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. > > I'm inclined to suggest if you opt in to an experimental language feature, you are by definition making at least an implicit declaration that you know what you're doing, so the idea people using these features wouldn't have the skills to spin up a container or install something on a VM doesn't convince me, personally.
