Re: Experimental features

> On 7 Oct 2022, at 18:44, Larry Garfield <larry@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 <cschneid@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.