Re: Experimental features
| From: | Alex Wells | Date: | Thu, 06 Oct 2022 11:16:57 +0000 |
| Subject: | Re: Experimental features | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-118764@lists.php.net to get a copy of this message | ||
> On 5 Oct 2022, at 20:41, Rowan Tommins <rowan.collins@gmail.com> wrote:
>
> On Wed, 5 Oct 2022 at 18:07, David Rodrigues <david.proweb@gmail.com> wrote:
>
>> 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.
>>
>
>
> 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.
>
> 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.
>
> 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?
>
> Regards,
> --
> 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.
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.