Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118806
Message-ID: <4D75B8A4-4134-4C60-9A02-AEB88799AA4A@gmail.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_1EA1D2FF-BB47-4627-9690-B52CB6E1D55D"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Date: Wed, 12 Oct 2022 11:39:16 +0300
In-Reply-To: <CAMrTa2EfY2Zxxuawm-oNAWicq7VP7L6G-EgcfpVAFoDOKGjFQg@mail.gmail.com>
Cc: David Rodrigues <david.proweb@gmail.com>,
 Larry Garfield <larry@garfieldtech.com>,
 php internals <internals@lists.php.net>
To: Jordan LeDoux <jordan.ledoux@gmail.com>
References: <CAEsg9X0YvRHHKCfFfkR3uYmzwpFps54GvmD7dCcJyXv3nwio-g@mail.gmail.com>
 <a187de08-9488-4407-9255-5bd57ee3daf6@app.fastmail.com>
 <CAEsg9X2KMAaZnSEqg+36-zZ-p49awoVeuRUnMm4PYJSGYZ--KA@mail.gmail.com>
 <CAMrTa2EfY2Zxxuawm-oNAWicq7VP7L6G-EgcfpVAFoDOKGjFQg@mail.gmail.com>
Subject: Re: [PHP-DEV] Feature preview (formely was: experimental features)
From: autaut03@gmail.com (Alex Wells)

--Apple-Mail=_1EA1D2FF-BB47-4627-9690-B52CB6E1D55D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On 12 Oct 2022, at 11:06, Jordan LeDoux <jordan.ledoux@gmail.com> =
wrote:
>=20
> If a "preview" doesn't allow us to make breaking changes, then what =
exactly
> is the point? I don't see any benefit at all to this without that.
>=20
> If the "preview" is *actually* just "put out an RFC in the next patch
> release as soon as it's merged to master", which is what it seems =
you're
> saying (as that seems like all that's left with all the things you =
said we
> can't do in a preview), then that seems dubious, prone to instability =
in
> the engine outside of the preview features, and a total breakage of =
the
> release cycle and RM process that is currently in place.

100% agree. Kotlin's experimental features are drastically different =
from what was described by David. I don't think "feature previews" =
deliver any value to PHP's development process here; mainly, it doesn't =
allow breaking changes, thus not allowing developers to be at ease when =
accepting features due to knowing they could make changes as they go, =
which I see as the main benefit.=20

It would have helped deliver features which were otherwise declined due =
to someone not liking the syntax, not seeing the usefulness or just not =
convinced. If a feature is proven to not be a good fit for PHP then it's =
removed.

Feature previews as I see it solve exactly one problem: feature's =
runtime stability - but I don't think this is a problem of PHP in the =
first place.=

--Apple-Mail=_1EA1D2FF-BB47-4627-9690-B52CB6E1D55D--