Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118742
MIME-Version: 1.0
References: <CAEsg9X3LGYQiF6PGgfhY9s=4iD5v0u2scFRyekNtJfcKDMijtQ@mail.gmail.com>
 <CAAwFBqoG0wjRxVXC8FvBHv5uCJYVYNJWLEGTnAX7DiYUO3rpVQ@mail.gmail.com>
In-Reply-To: <CAAwFBqoG0wjRxVXC8FvBHv5uCJYVYNJWLEGTnAX7DiYUO3rpVQ@mail.gmail.com>
Date: Wed, 5 Oct 2022 00:47:09 +0200
Message-ID: <CAJmy8YFB30Wk9t9_hF7rtCKnhcO48pHdVeMRqh6heLRqaKA+Tw@mail.gmail.com>
To: =?UTF-8?Q?Fl=C3=A1vio_Heleno?= <flaviohbatista@gmail.com>
Cc: David Rodrigues <david.proweb@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Experimental features
From: divinity76@gmail.com (Hans Henrik Bergan)

sounds like that's been done with PECL previously yeah?
PECL json until native json_encode in PHP5.2.0,
PECL PDO until native PDO in PHP 5.1.0,
PECL ZendOpcache until native opcache in PHP 5.5.5
etc?

On Wed, 5 Oct 2022 at 00:38, Fl=C3=A1vio Heleno <flaviohbatista@gmail.com> =
wrote:
>
> On Tue, Oct 4, 2022, 17:43 David Rodrigues <david.proweb@gmail.com> wrote=
:
>
> > I wanted to suggest the possibility of introducing experimental feature=
s to
> > PHP.
> >
> > This is an old thread I guess, but I think it's good to reevaluate the
> > situation from time to time, as other languages already do this to some
> > extent and PHP doesn't. Some platforms/languages (Node, Kotlin) and
> > libraries (React) bring features natively in an experimental way.
> >
> > I wanted to propose that we bring this idea into PHP, so we wouldn't ha=
ve
> > to wait for new major/minor versions (eg. 9.0 or 8.2, 8.3) to try out t=
hese
> > new features, and so when these versions arrive, they'll already be qui=
te
> > polished, avoiding patches sometime later due to wider usage of users.
> >
> > My idea is to have two levels of experimental features:
> >
> > (1) Via declare(), when the feature affects how PHP can act when readin=
g
> > the file itself. Eg. declare(experimental_operator_override =3D
> > true), Something that happens with Kotlin, for example, when we use som=
e
> > experimental annotations like contracts. These declarations work "per
> > file", so whenever it is necessary to use it, it must be declared.
> >
> > (2) Via experimental identifier name. Eg. experimental_json_validate() =
or
> > Experimental::json_validate(), like in Kotlin and also in React.
> >
> > Experimental features can only be brought into a minor version (eg. PHP
> > 8.1.12) when it is minimally refined and practically ready to use. It w=
ould
> > be "kind of" an expected final version, no new patches are expected (we
> > hope), unless something really went unnoticed.
> >
> > Despite this, experimental features may not exist until the next
> > major/minor release if its practical inefficiency is found or if the
> > concept is shown to be invalid. So it should always be a "use with care=
".
> >
> > However, if an experimental feature is successful, it becomes final at =
the
> > next major/minor or major/minor+1. The experimental version becomes an
> > alias during some future versions until it is removed entirely. This is=
 the
> > time for users to adapt their code and for IDEs to help us find them.
> >
> > With this, we can understand whether users are making use of a certain
> > feature or not, make improvements on it, etc.
> >
> > I notice that many good features are rejected because they are believed=
 to
> > be bad for PHP or can be confusing, but without any practical testing.
> > Experimental features can make this analysis more grounded in practical
> > data than just possibilities.
> >
> > However, this also doesn't mean that any idea can become an experimenta=
l
> > feature, but ideas that have a good foundation and a good discussion be=
fore
> > it. The difference is that the feature can be tested in practice before
> > being totally rejected, and approved features can be delivered ahead of
> > time to refine before the next version is released, allowing users to t=
ry
> > them out more easily.
> >
> >
> > Atenciosamente,
> > David Rodrigues
> >
>
> Hi David,
>
> Could this be done through extensions instead of having to develop a new
> process/support code?
>
> When json support was first introduced into php, it was done as an
> extension and then, after a while, incorporated into the core.