Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118740
MIME-Version: 1.0
Date: Tue, 4 Oct 2022 17:42:28 -0300
Message-ID: <CAEsg9X3LGYQiF6PGgfhY9s=4iD5v0u2scFRyekNtJfcKDMijtQ@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000047bc3905ea3b80db"
Subject: Experimental features
From: david.proweb@gmail.com (David Rodrigues)

--00000000000047bc3905ea3b80db
Content-Type: text/plain; charset="UTF-8"

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

--00000000000047bc3905ea3b80db--