Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118764
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
In-Reply-To: <CALKiJKqcwkMW8Dw9Htxzt=Swkz08uY5XNEOrLq2qEsyTrJczTA@mail.gmail.com>
Date: Thu, 6 Oct 2022 14:16:57 +0300
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <C45353A1-0666-4857-AC9F-99DA0BB90031@gmail.com>
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>
To: Rowan Tommins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] Experimental features
From: autaut03@gmail.com (Alex Wells)



> On 5 Oct 2022, at 20:41, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>=20
> On Wed, 5 Oct 2022 at 18:07, David Rodrigues <david.proweb@gmail.com> =
wrote:
>=20
>> Another advantage in this sense is that it would be possible to have =
a
>> single development branch for PHP 8.1 (current version) and 8.2
>> (development version), for example, with the difference of some =
definitions
>> in the code that activate or deactivate the experimental features =
already
>> developed for the future version.
>>=20
>=20
>=20
> The problem I predict with this is that unless they have a convenient =
"hook
> point", experimental features would lead to ugly code: they need to be
> enabled at run-time rather than build-time, so are hard to optimise; =
and
> they are going to be released after a short test cycle, so need to =
avoid
> refactoring.
>=20
> Maybe there are enough "hook points" in the engine that some =
categories of
> feature could be implemented without too much disruption, but it's a
> complex beast with a shortage of experts, so I'm wary of adding more
> complexity.
>=20
> I also agree with the previous comment that this would need to be =
coupled
> with some way of monitoring the results - imagine we released an
> experimental feature 3 months ago, what do we do exactly to find out =
if it
> needs changing?
>=20
> Regards,
> --=20
> Rowan Tommins
> [IMSoP]

A marker merely just tells the compiler "hey, allow me to use this =
feature right here", i.e. it denotes a piece of code as allowed to use =
the feature, not enable it. Effectively, all experimental features are =
just regular features that are "always on" and hence can be optimized =
the same way regular features are. The marker serves two purposes: allow =
simple discovery of usages (by the compiler or other tools) and force =
the developer to acknowledge they're using an experimental feature with =
an unstable API/syntax/spec.=20

Regarding the monitoring - that is a problem that needs to be solved and =
there are multiple solutions: GitHub issues, corporate/public messengers =
(Slack?) or the internals mailing list.=