Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118775
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Date: Fri, 7 Oct 2022 08:57:26 +0200
References: <CAEsg9X3LGYQiF6PGgfhY9s=4iD5v0u2scFRyekNtJfcKDMijtQ@mail.gmail.com>
 <CAAwFBqoG0wjRxVXC8FvBHv5uCJYVYNJWLEGTnAX7DiYUO3rpVQ@mail.gmail.com>
 <CABigaAU+eR718cEHUmwxNdBuMyQSwKkhnR2SfMo1otiMwrq+jg@mail.gmail.com>
 <EB5DD38F-6A46-4D07-B011-00179E91724C@cschneid.com>
 <CAEsg9X0DAh+Y45LUdG=aFOo4cWvmBU2Vfg48YcnsQkdh1grEdg@mail.gmail.com>
 <CALKiJKqcwkMW8Dw9Htxzt=Swkz08uY5XNEOrLq2qEsyTrJczTA@mail.gmail.com>
 <C45353A1-0666-4857-AC9F-99DA0BB90031@gmail.com>
 <1aa20877-3365-0ace-25d2-1cb1be8f3bcc@gmail.com>
 <55686BD4-4C67-4A4F-8BE4-BDF0149296FB@gmail.com>
 <a2c2c00a-9bad-77e7-0bb6-9c91f1cc250b@gmail.com>
 <CAEsg9X1vRehZYk1BWME1hjq6PkZ1npA1uy4ueSJ0ak1Ynw0rCQ@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
In-Reply-To: <CAEsg9X1vRehZYk1BWME1hjq6PkZ1npA1uy4ueSJ0ak1Ynw0rCQ@mail.gmail.com>
Message-ID: <95467744-C4FC-45F9-9A5B-E3A8B9790074@cschneid.com>
Subject: Re: [PHP-DEV] Experimental features
From: cschneid@cschneid.com (Christian Schneider)

Am 06.10.2022 um 23:40 schrieb David Rodrigues <david.proweb@gmail.com>:
> But keep in mind that these features are already intended for PHP, and =
it
> is not a "feature test" or suggestion. The voting process is mandatory =
and
> the feature must already be set to "accepted".

Just so I understand what you are saying: You would only add things to =
experimental where an RFC for it has been accepted?
What you basically want to do is to introduce such features into the =
current stable branch instead of the upcoming one, right?

> However, we need to separate an experimental feature into stages, much =
like
> Node does, so these are my suggestions:

[...]

> 2. Open experimental: the feature has already been state internally by
> "adventurous users" and can already be used without php.ini =
configurations,
> however, its use in code still needs experimental markers (eg.
> experimental_json_validate() or declare(experimental_*)). BC is =
unlikely to
> happen unless the feature has issues that need to be resolved before =
an
> official release. Removing the feature is suggested not to happen, =
with the
> exception of very serious and irreparable issues.

One side-note here: I would strongly advise not to use an experimental_ =
prefix or package for functions because it would be a PITA to make code =
compatible with different versions, one where the function has the =
experimental_ prefix / package and one where it doesn't.

But now to my main point: You are talking about the most simple and =
isolated case, a new function.
Your model may work fine with that but as soon as we are talking =
something like a syntax change we have some additional problems:
- Enabling it with a prefix obviously does not work, something like =
declare() is definitely needed
- Maintaining such changes to the engine / parser could turn out messy, =
e.g. lots of "if (experimental_x)"-like code in the core
- The test suite would possibly have to deal with an exponential =
explosion of experimental feature combinations to make sure they don't =
interfere with each other.

All in all I'm not sold yet that the benefit outweighs the cost of this =
approach.

Regards,
- Chris