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.
