Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118799
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
In-Reply-To: <29756830-87E9-468B-92B8-3D0906A2A34C@cschneid.com>
Date: Tue, 11 Oct 2022 14:40:53 -0400
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <BCC89502-527E-4610-9118-AAFB35D04A27@newclarity.net>
References: <CAEsg9X3LGYQiF6PGgfhY9s=4iD5v0u2scFRyekNtJfcKDMijtQ@mail.gmail.com>
 <CA+p1FaZqJKFqHdRVqP9xqpHRJoJpKEXbBeo6qTtoeXhZs8oUkQ@mail.gmail.com>
 <CAEsg9X1AztFeF_AvN57wc+CqfAefzsfmy3OG8ZmeRqvk-fcR3w@mail.gmail.com>
 <CA+p1Fabc4bNK1XLy66D5Yc8CRCKf1LqD5jZNFtxhO5ecs0w+5Q@mail.gmail.com>
 <5EBAAEBD-4F9E-4832-BBDD-6E67D8758490@gmail.com>
 <29756830-87E9-468B-92B8-3D0906A2A34C@cschneid.com>
To: Christian Schneider <cschneid@cschneid.com>
Subject: Re: [PHP-DEV] Experimental features
From: mike@newclarity.net (Mike Schinkel)

> On Oct 11, 2022, at 8:24 AM, Christian Schneider =
<cschneid@cschneid.com> wrote:
>=20
> We seem to have two different views on experimental feature here: You =
are saying they could get removed again while others stated it is for =
stuff which will definitely end up in stable when the next major release =
is done.
>=20
> IMHO there needs to be a consensus about this before we can continue =
the discussion, otherwise we will go around in circles.

True. In my view experimental would allow to features to be tried that =
might get removed, but others may not want that.

However, I think it is really a moot point because of RFC voting. If =
enough people felt it might get removed they would vote against it. And =
if after something was experimental if enough people felt it should be =
removed they would vote to do so.

So each individual RFC as well as voting addresses that concern.

> That's another thing where we need to find an agreement first: Are we =
talking new, isolated functions or are we possibly also talking about =
core new language features (i.e. new syntax / semantics)?
>=20
> The work for maintenance by core developers could be much higher if it =
is not limited to new functions.
> This is IMHO an important aspect as we do not want to make life even =
harder for the core team.

Again, each individual RFC and voting address that concern.=20

If an experimental RFC would resolve it "too much" maintenance by core =
developers then it would get voted down. A 2/3rd bar for success is not =
a low bar, especially in a community with so many divergent opinions.=20

> Hot take: If it is only about new functions then we don't need =
anything in the core, just create an \Experimental package with poyfills =
and you're done ;-)

My hot take: Having the entire PHP community made aware of a given =
experimental function =E2=80=94 including all the blog posts that would =
be written about it =E2=80=94 is !=3D to an individual developer =
creating an \Experimental namespace and writing their own blog post =
about it.=20

>> Not all potentially useful functions can reasonably be implemented in =
userland PHP.
>=20
> ... but almost all of them can.

See reply in prior paragraph.

> I'd go as far as saying that while emulating json_validate() using =
json_decode()  is slower and uses more memory it still is a valid =
polyfill. It is IMHO easy enough to develop with a higher memory limit =
and performance is not that critical for development either.

For json_validate() people have *already* been using a polyfill, and it =
was found sorely lacking for memory-use reasons.  So a reason for making =
it experimental would be to see if the proposed signature was sufficient =
for mainstream needs.

Oh, and a higher memory limit is not always a viable solution.

> And unless you want to ship experimental code to production (which you =
shouldn't) you will have to wait for the next major PHP release anyway.

Not all "production" code is equal. My blog !=3D Wikipedia, for example.

-Mike=