Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118790
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
In-Reply-To: <CA+p1FaZqJKFqHdRVqP9xqpHRJoJpKEXbBeo6qTtoeXhZs8oUkQ@mail.gmail.com>
Date: Mon, 10 Oct 2022 19:06:03 -0400
Cc: David Rodrigues <david.proweb@gmail.com>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <8E68EB91-5B02-4DC8-952B-51E71303DF05@newclarity.net>
References: <CAEsg9X3LGYQiF6PGgfhY9s=4iD5v0u2scFRyekNtJfcKDMijtQ@mail.gmail.com>
 <CA+p1FaZqJKFqHdRVqP9xqpHRJoJpKEXbBeo6qTtoeXhZs8oUkQ@mail.gmail.com>
To: David Gebler <davidgebler@gmail.com>
Subject: Re: [PHP-DEV] Experimental features
From: mike@newclarity.net (Mike Schinkel)

> On Oct 10, 2022, at 6:20 PM, David Gebler <davidgebler@gmail.com> =
wrote:
>=20
> My two cents...
>=20
> Why can't "common users" install a PECL extension? It's not a =
difficult,
> obscure or undocumented process.

A lot of developers (most?) who build PHP applications run them in =
shared-hosted or managed hosted servers where are never given the option =
to install a PECL extension.=20

In the rare cases they can install PECL many of those PHP developers =
would not have the skills to do it or the requisite permissions on the =
server; I certainly did not for the first ~10 years of working with PHP. =
I do now, but ironically because I have mostly moved away from =
programming in PHP to do more DevOps work.

Further, when working in multiple environments having to set up each =
server to have all the same PECL installations can be just too much =
hurdle so that developers won't even try, especially when working in =
managed environments.

[1] https://stackoverflow.com/a/12750694/102699


> I can accept the reasoning
>=20
>> Apply a PECL strategy to try experimental features might not be the
> convenient way always, for example, if we create a new ... sensitive =
ini
> setting that affects the behavior of PHP somehow... OR ... what about =
a new
> sensitive funtion in a "core extension" like JSON?
>=20
> But why would the answer in those cases not be "compile the PHP =
fork/branch
> with the experimental feature", rather than find a way to flag the =
engine
> to switch arbitrary new features on or off, complete with all the
> complications in the primary source code that would cause? We are, =
after
> all, talking about features which by definition should not be relied =
upon
> for any production use.
>=20
> Or we're talking about features which are stable and valuable enough =
to
> have passed an RFC process, but then what's gained from an =
experimental
> designation? Why couldn't they just be included in a preview/beta/RC
> version which anyone could decide to run or not?

It does not seem reasonable that the bar to include a feature as =
experimental should be the same bar as currently exists for forever =
features.  Opinions expressed on the list typically fall into one of =
three categories: =20

1.) Please, please yes!=20
2.) No way whatsoever! or=20
3.) I am not convinced...

Generally it seems that unless 2/3rd are in the #1 category an RFC fails =
to pass, even if after evaluating in the wild the people in group #3 =
might come to see a lot of value in it and some in #2 might even change =
their mind. In those cases PHP suffers.=20

If there were an RFC for Experimental Use then the people on the fence =
could choose to allow it to see how it plays out in real-world userland =
cases, and a few people against it might be convinced to allow people to =
evaluate it, and then later make a decision on a "Forever RFC."

---------------

Also, the comments along the lines of "Well, this could quickly get out =
of hand" presume that the people voting for experimental use won't take =
that into consideration and vote against things if it seems like things =
are in-fact getting out of hand. But they will take that into =
consideration just a as the take other concerns into consideration now, =
and thus only the better ideas will be likely to make it through to =
experimental status.

---------------

One more thing on this topic. PHP could ALSO allow experimental features =
to be written in PHP, and ship those experimental features with PHP so =
that code would always be available, at least when experimental features =
are turned on, and without having to include said code. =20

The benefit there would be people could more quickly implement an =
experimental feature to see how it might work in the wild before going =
to all the effort to implement in C in PHP's core code, for things that =
can be implemented in PHP.

-Mike