Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118741
MIME-Version: 1.0
References: <CAEsg9X3LGYQiF6PGgfhY9s=4iD5v0u2scFRyekNtJfcKDMijtQ@mail.gmail.com>
In-Reply-To: <CAEsg9X3LGYQiF6PGgfhY9s=4iD5v0u2scFRyekNtJfcKDMijtQ@mail.gmail.com>
Date: Tue, 4 Oct 2022 19:37:47 -0300
Message-ID: <CAAwFBqoG0wjRxVXC8FvBHv5uCJYVYNJWLEGTnAX7DiYUO3rpVQ@mail.gmail.com>
To: David Rodrigues <david.proweb@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000009048ef05ea3d1cec"
Subject: Re: [PHP-DEV] Experimental features
From: flaviohbatista@gmail.com (=?UTF-8?Q?Fl=C3=A1vio_Heleno?=)

--0000000000009048ef05ea3d1cec
Content-Type: text/plain; charset="UTF-8"

On Tue, Oct 4, 2022, 17:43 David Rodrigues <david.proweb@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.

--0000000000009048ef05ea3d1cec--