Hi Flávio and Hans! > Could this be done through extensions instead of having to develop a new process/support code?
I believe it is possible, however, the main part of the idea would be that "common users" could try out the features without having to know how to install extensions, while there is an explicit notion that the feature used is experimental (via experimental_() prefix for functions or method, for instance) and that the goal is to test it to become part of PHP itself at some point, not more as an extension but as a native part. So if these experimental extensions are available natively and enabled by default, it would be interesting, because it would be easier to separate the main code from the code in development/refinement (and that can be rejected at some point in a more practical way, and maybe be kept as just an extension apart from PHP). Atenciosamente, David Rodrigues Em ter., 4 de out. de 2022 às 19:37, Flávio Heleno <flaviohbati...@gmail.com> escreveu: > 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. > > >
