Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118776
MIME-Version: 1.0
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>
In-Reply-To: <95467744-C4FC-45F9-9A5B-E3A8B9790074@cschneid.com>
Date: Fri, 7 Oct 2022 11:58:07 +0100
Message-ID: <CAFPFaMJr7oGdFcLyz9gPq-uAFRk2GeghRvjT-y=Rwwge3EHeUQ@mail.gmail.com>
To: Christian Schneider <cschneid@cschneid.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000fff54e05ea6faf41"
Subject: Re: [PHP-DEV] Experimental features
From: george.banyard@gmail.com ("G. P. B.")

--000000000000fff54e05ea6faf41
Content-Type: text/plain; charset="UTF-8"

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

--000000000000fff54e05ea6faf41--