Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118782
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: <2cca6ce9-409a-4af3-b947-c47b0d689b48@app.fastmail.com>
Date: Fri, 7 Oct 2022 18:58:54 +0300
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <D442EDCA-DDC4-45AF-AFF2-5AF957FFA0E6@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>
 <C45353A1-0666-4857-AC9F-99DA0BB90031@gmail.com>
 <1aa20877-3365-0ace-25d2-1cb1be8f3bcc@gmail.com>
 <55686BD4-4C67-4A4F-8BE4-BDF0149296FB@gmail.com>
 <a2c2c00a-9bad-77e7-0bb6-9c91f1cc250b@gmail.com>
 <CAEsg9X1vRehZYk1BWME1hjq6PkZ1npA1uy4ueSJ0ak1Ynw0rCQ@mail.gmail.com>
 <95467744-C4FC-45F9-9A5B-E3A8B9790074@cschneid.com>
 <CAFPFaMJr7oGdFcLyz9gPq-uAFRk2GeghRvjT-y=Rwwge3EHeUQ@mail.gmail.com>
 <2cca6ce9-409a-4af3-b947-c47b0d689b48@app.fastmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Subject: Re: [PHP-DEV] Experimental features
From: autaut03@gmail.com (Alex Wells)



> On 7 Oct 2022, at 18:44, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=20
> 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:
>>=20
>>> But now to my main point: You are talking about the most simple and
>>> isolated case, a new function.
>>>=20
>>=20
>> I agree, and for most intent and purposes a function can be =
polyfilled in
>> userland. So this is the least interesting case.
>>=20
>> 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.
>>=20
>>=20
>>> 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.
>>>=20
>>> All in all I'm not sold yet that the benefit outweighs the cost of =
this
>>> approach.
>>>=20
>>=20
>> Ditto.
>>=20
>> When Nikita proposes editions back in 2020 (
>> =
https://github.com/nikic/php-rfcs/blob/language-evolution/rfcs/0000-langua=
ge-evolution.md)
>> the point about them was mainly about backwards-incompatible changes,=20=

>> 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=20
>> thinking
>> about the design of it instead of just shoving something in php-src
>> randomly as in the before days.
>>=20
>> Best regards,
>>=20
>> George P. Banyard
>=20
> 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.
>=20
> 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.
>=20
> Some candidates to consider could be:
>=20
> 1. Named args
> 2. PIpes
> 3. PFA
> 4. Intersection types
> 5. Enums
> 6. JIT
> 7. FFI
>=20
> Personally I'm still highly skeptical that this would be useful, or =
useful enough to justify the engine complexity. =20
>=20
> 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.
>=20
> We should learn from that experience.
>=20
> --Larry Garfield
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>=20

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.=