Hey. Experimental features have been briefly discussed before in https://github.com/PHPGenerics/php-generics-rfc/issues/49. I believe this is a good starting point to understand how it's different to extensions or otherwise different builds of PHP.
Advantages of experimental features over extensions: - they allow changes to the parser - they are universally supported (by IDE's, parsers etc) because they are part of a stable language release, not an unpopular/unknown extension - usages of them can be found in a codebase and then analysed (unlike extensions that don't have any kind of marker to denote them from regular code) - it's easy to implement a universal warning mechanism - for IDEs, static analysers and PHP itself to warn users about the consequences of using an experimental feature - they don't need a versioning mechanism, because they are effectively always "alpha" - i.e. non-stable, so any PHP release can introduce a breaking change into an experimental feature On Wed, Oct 5, 2022 at 1:38 AM Flávio Heleno <flaviohbati...@gmail.com> wrote: > On Tue, Oct 4, 2022, 17:43 David Rodrigues <david.pro...@gmail.com> wrote: > > > I wanted to suggest the possibility of introducing experimental features > to > > PHP. > > > > This is an old thread I guess, but I think it's good to reevaluate the > > situation from time to time, as other languages already do this to some > > extent and PHP doesn't. Some platforms/languages (Node, Kotlin) and > > libraries (React) bring features natively in an experimental way. > > > > I wanted to propose that we bring this idea into PHP, so we wouldn't have > > to wait for new major/minor versions (eg. 9.0 or 8.2, 8.3) to try out > these > > new features, and so when these versions arrive, they'll already be quite > > polished, avoiding patches sometime later due to wider usage of users. > > > > My idea is to have two levels of experimental features: > > > > (1) Via declare(), when the feature affects how PHP can act when reading > > the file itself. Eg. declare(experimental_operator_override = > > true), Something that happens with Kotlin, for example, when we use some > > experimental annotations like contracts. These declarations work "per > > file", so whenever it is necessary to use it, it must be declared. > > > > (2) Via experimental identifier name. Eg. experimental_json_validate() or > > Experimental::json_validate(), like in Kotlin and also in React. > > > > Experimental features can only be brought into a minor version (eg. PHP > > 8.1.12) when it is minimally refined and practically ready to use. It > would > > be "kind of" an expected final version, no new patches are expected (we > > hope), unless something really went unnoticed. > > > > Despite this, experimental features may not exist until the next > > major/minor release if its practical inefficiency is found or if the > > concept is shown to be invalid. So it should always be a "use with care". > > > > However, if an experimental feature is successful, it becomes final at > the > > next major/minor or major/minor+1. The experimental version becomes an > > alias during some future versions until it is removed entirely. This is > the > > time for users to adapt their code and for IDEs to help us find them. > > > > With this, we can understand whether users are making use of a certain > > feature or not, make improvements on it, etc. > > > > I notice that many good features are rejected because they are believed > to > > be bad for PHP or can be confusing, but without any practical testing. > > Experimental features can make this analysis more grounded in practical > > data than just possibilities. > > > > However, this also doesn't mean that any idea can become an experimental > > feature, but ideas that have a good foundation and a good discussion > before > > it. The difference is that the feature can be tested in practice before > > being totally rejected, and approved features can be delivered ahead of > > time to refine before the next version is released, allowing users to try > > them out more easily. > > > > > > Atenciosamente, > > David Rodrigues > > > > Hi David, > > Could this be done through extensions instead of having to develop a new > process/support code? > > When json support was first introduced into php, it was done as an > extension and then, after a while, incorporated into the core. >
