Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118743
MIME-Version: 1.0
References: <CAEsg9X3LGYQiF6PGgfhY9s=4iD5v0u2scFRyekNtJfcKDMijtQ@mail.gmail.com>
 <CAAwFBqoG0wjRxVXC8FvBHv5uCJYVYNJWLEGTnAX7DiYUO3rpVQ@mail.gmail.com>
In-Reply-To: <CAAwFBqoG0wjRxVXC8FvBHv5uCJYVYNJWLEGTnAX7DiYUO3rpVQ@mail.gmail.com>
Date: Tue, 4 Oct 2022 19:52:04 -0300
Message-ID: <CAEsg9X0YmHEqcoE27rGK2ixndSHFNAeCJcSC4JGvdFu6daz-cg@mail.gmail.com>
To: =?UTF-8?Q?Fl=C3=A1vio_Heleno?= <flaviohbatista@gmail.com>, 
	Hans Henrik Bergan <divinity76@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000cf0a2c05ea3d4fc0"
Subject: Re: [PHP-DEV] Experimental features
From: david.proweb@gmail.com (David Rodrigues)

--000000000000cf0a2c05ea3d4fc0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Fl=C3=A1vio and Hans!

> Could this be done through extensions instead of having to develop a new
process/support code?

I believe it is possible, however, the main part of the idea would be that
"common users" could try out the features without having to know how to
install extensions, while there is an explicit notion that the feature used
is experimental (via experimental_() prefix for functions or method, for
instance) and that the goal is to test it to become part of PHP itself at
some point, not more as an extension but as a native part. So if these
experimental extensions are available natively and enabled by default, it
would be interesting, because it would be easier to separate the main code
from the code in development/refinement (and that can be rejected at some
point in a more practical way, and maybe be kept as just an extension apart
from PHP).




Atenciosamente,
David Rodrigues


Em ter., 4 de out. de 2022 =C3=A0s 19:37, Fl=C3=A1vio Heleno <flaviohbatist=
a@gmail.com>
escreveu:

> On Tue, Oct 4, 2022, 17:43 David Rodrigues <david.proweb@gmail.com> wrote=
:
>
>> I wanted to suggest the possibility of introducing experimental features
>> 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 hav=
e
>> to wait for new major/minor versions (eg. 9.0 or 8.2, 8.3) to try out
>> these
>> new features, and so when these versions arrive, they'll already be quit=
e
>> 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 reading
>> the file itself. Eg. declare(experimental_operator_override =3D
>> true), Something that happens with Kotlin, for example, when we use some
>> 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() o=
r
>> 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
>> would
>> 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 t=
he
>> 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 experimental
>> feature, but ideas that have a good foundation and a good discussion
>> before
>> 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 tr=
y
>> 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.
>
>
>

--000000000000cf0a2c05ea3d4fc0--