Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118789
MIME-Version: 1.0
References: <CAEsg9X3LGYQiF6PGgfhY9s=4iD5v0u2scFRyekNtJfcKDMijtQ@mail.gmail.com>
 <CA+p1FaZqJKFqHdRVqP9xqpHRJoJpKEXbBeo6qTtoeXhZs8oUkQ@mail.gmail.com>
In-Reply-To: <CA+p1FaZqJKFqHdRVqP9xqpHRJoJpKEXbBeo6qTtoeXhZs8oUkQ@mail.gmail.com>
Date: Mon, 10 Oct 2022 20:05:13 -0300
Message-ID: <CAEsg9X1AztFeF_AvN57wc+CqfAefzsfmy3OG8ZmeRqvk-fcR3w@mail.gmail.com>
To: David Gebler <davidgebler@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e0c97105eab631d4"
Subject: Re: [PHP-DEV] Experimental features
From: david.proweb@gmail.com (David Rodrigues)

--000000000000e0c97105eab631d4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

The idea is that the experimental features are exclusively something that
the PHP team has voted for (approved) and that will be part of the language=
.

Users can choose to install PECL, but it is not the same, because it
depends on other users (who can make use of this code) having the notion
that a certain PECL will be necessary.

Imagine a package under development (eg. Laravel 10) that is (supposing
that) intended to be released compatible with PHP 8.3 (supposing that it
already has experimental features). In this case, the Laravel team can
start using an experimental feature while developing Laravel 10, waiting
for the release of PHP 8.3. Once the PHP 8.3 release is finished, Laravel
10 can just remove the experimental tags and release its new version fastly=
.

The user, on condition that he is willing to use Laravel 10 (in
development) will make indirect use of experimental features. Then both the
Laravel team and these users will be able to provide feedback for these
features to the PHP team before the official release.

Like json_validate(): assuming Laravel needs to check if a code is valid
JSON, but without processing its data for use. It could check if PHP >=3D
8.3, so use experimental_json_validate(), else use previous PHP compatible
code.


Atenciosamente,
David Rodrigues


Em seg., 10 de out. de 2022 =C3=A0s 19:20, David Gebler <davidgebler@gmail.=
com>
escreveu:

> My two cents...
>
> Why can't "common users" install a PECL extension? It's not a difficult,
> obscure or undocumented process.
>
> I can accept the reasoning
>
> > Apply a PECL strategy to try experimental features might not be the
> convenient way always, for example, if we create a new ... sensitive ini
> setting that affects the behavior of PHP somehow... OR ... what about a n=
ew
> sensitive funtion in a "core extension" like JSON?
>
> But why would the answer in those cases not be "compile the PHP
> fork/branch with the experimental feature", rather than find a way to fla=
g
> the engine to switch arbitrary new features on or off, complete with all
> the complications in the primary source code that would cause? We are,
> after all, talking about features which by definition should not be relie=
d
> upon for any production use.
>
> Or we're talking about features which are stable and valuable enough to
> have passed an RFC process, but then what's gained from an experimental
> designation? Why couldn't they just be included in a preview/beta/RC
> version which anyone could decide to run or not?
>

--000000000000e0c97105eab631d4--