> On 5 Oct 2022, at 20:41, Rowan Tommins <rowan.coll...@gmail.com> wrote:
>
> On Wed, 5 Oct 2022 at 18:07, David Rodrigues <david.pro...@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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
