> On 7 Oct 2022, at 18:44, Larry Garfield <la...@garfieldtech.com> wrote:
>
> On Fri, Oct 7, 2022, at 5:58 AM, G. P. B. wrote:
>> On Fri, 7 Oct 2022 at 07:57, Christian Schneider <cschn...@cschneid.com>
>> wrote:
>>
>>> But now to my main point: You are talking about the most simple and
>>> isolated case, a new function.
>>>
>>
>> I agree, and for most intent and purposes a function can be polyfilled in
>> userland. So this is the least interesting case.
>>
>> However, I don't think this approach is that useful. To give an example,
>> for DNF types the implementation is based on a change in how iterable works
>> in PHP.
>> It went from a pseudo-type to a compile time alias, as this massively
>> simplified variance and LSP checks.
>> I would not want such a change to land in a patch release especially as it
>> turned out there was an unintended BC break with the compile time
>> redundancy which only got fixed in PHP8.2RC2.
>>
>>
>>> 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.
>>>
>>
>> Ditto.
>>
>> When Nikita proposes editions back in 2020 (
>> https://github.com/nikic/php-rfcs/blob/language-evolution/rfcs/0000-language-evolution.md)
>> the point about them was mainly about backwards-incompatible changes,
>> not
>> new features.
>> Because in general new features don't have the same issues, especially
>> since the RFC process (although not without its issues) does force
>> thinking
>> about the design of it instead of just shoving something in php-src
>> randomly as in the before days.
>>
>> Best regards,
>>
>> George P. Banyard
>
> I think what would be useful here to better understand the value, if any,
> would be to look back at some recent RFCs, both those that passed and those
> that didn't, and imagine how they would have gone had there been an
> "experimental" flag option for them.
>
> Would they have been marked experimental at all? Why?
> What might have changed and when while in experimental phase?
> When would they have been removed instead of being adjusted?
> Etc.
>
> Some candidates to consider could be:
>
> 1. Named args
> 2. PIpes
> 3. PFA
> 4. Intersection types
> 5. Enums
> 6. JIT
> 7. FFI
>
> Personally I'm still highly skeptical that this would be useful, or useful
> enough to justify the engine complexity.
>
> Bear in mind that browsers had "experimental" CSS features for a while, and
> eventually abandoned prefixing as it was an absolute mess as the experimental
> features ended up in production and then had to be supported forever in that
> early, broken form. Instead, they switched to an opt-in flag in browser
> configuration (~php.ini setting) on the assumption that devs could play with
> it, but *it was completely impractical to ship to production* so no one did,
> so they could still change it. Experimental features never leave the dev's
> own computer until they are no longer experimental. That has worked out a
> lot better.
>
> We should learn from that experience.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
I don't think it's valid to compare browser (client side) and PHP (server
side): browser versions and support is not controlled by the server, so it's
not fair to expect client-side experimental features to perform as good as
server-side ones. If there's anyone to learn from, it should be Kotlin or other
server languages.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
