sounds like that's been done with PECL previously yeah? PECL json until native json_encode in PHP5.2.0, PECL PDO until native PDO in PHP 5.1.0, PECL ZendOpcache until native opcache in PHP 5.5.5 etc?
On Wed, 5 Oct 2022 at 00:38, 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
