Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118787
Message-ID: <cb1d6aae-aed2-bc95-2cd7-51014df7e7c1@gmail.com>
Date: Sat, 8 Oct 2022 19:31:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.1
To: internals@lists.php.net
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>
Content-Language: en-GB
In-Reply-To: <2cca6ce9-409a-4af3-b947-c47b0d689b48@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Experimental features
From: rowan.collins@gmail.com (Rowan Tommins)

On 07/10/2022 16:44, Larry Garfield wrote:
> 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.


That's an interesting thought experiment. Here are the thoughts that 
occur to me:


> Some candidates to consider could be:
>
> 1. Named args


Possibly an experimental phase would have given more time for the names 
of arguments on internal functions to be decided. Some third-party 
libraries might also have taken advantage of that timescale, although 
some would still have decided to simply say names are not guaranteed to 
be stable.


> 2. Pipes
> 3. PFA


If experimental features had a lower voting threshold, perhaps these 
would have been accepted at that stage; but I'm not sure what would 
happen during that phase that would prevent them being rejected as a 
permanent feature.


> 4. Intersection types


Anything that leads to complex changes in the engine can realistically 
only be released in an annual .0 release, because the alpha & beta 
period is essential to spot regressions to existing functionality. That 
means an experimental flag will only ever mean waiting longer to use 
such features in production, not getting them sooner.

The only benefit would therefore be if there are behaviour details that 
are "locked in" which could have been changed if they were marked 
experimental; I'm not aware of any in this case, but it does happen - 
the discussions around readonly classes and inheritance come close, 
although allowing something that was previously forbidden at 
compile-time is generally not considered a BC break anyway.


> 6. JIT


This is already behind a run-time flag, and exposes very little direct 
API, so an "experimental" release would mostly be a question of 
documentation (on php.net, and in the shipped sample ini files), and the 
compiled-in default for the flag. That wouldn't have needed any new policy.


> 7. FFI


This *does* include a user-facing API, and that API has a few rough 
edges. However, it was developed entirely as an extension, and we 
already have a mechanism for marking those experimental: ship them in 
PECL first, and allow breaking changes while bundling into the main 
source tree. This happened with ext/sodium for instance. Why it didn't 
happen with FFI, I'm not entirely sure.

The same *might* go for Fibers, although delivery as an extension would 
probably require a different implementation from what we have. I'm not 
sure it would have made sense to ship it in a state that made changes to 
the engine, requiring changes to other extensions to be compatible, but 
then make users wait before using it in production.


Regards,

-- 
Rowan Tommins
[IMSoP]