Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118755
MIME-Version: 1.0
References: <CAEsg9X3LGYQiF6PGgfhY9s=4iD5v0u2scFRyekNtJfcKDMijtQ@mail.gmail.com>
 <CAAwFBqoG0wjRxVXC8FvBHv5uCJYVYNJWLEGTnAX7DiYUO3rpVQ@mail.gmail.com>
 <CABigaAU+eR718cEHUmwxNdBuMyQSwKkhnR2SfMo1otiMwrq+jg@mail.gmail.com> <EB5DD38F-6A46-4D07-B011-00179E91724C@cschneid.com>
In-Reply-To: <EB5DD38F-6A46-4D07-B011-00179E91724C@cschneid.com>
Date: Wed, 5 Oct 2022 14:06:58 -0300
Message-ID: <CAEsg9X0DAh+Y45LUdG=aFOo4cWvmBU2Vfg48YcnsQkdh1grEdg@mail.gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000006f5fc705ea4c9b3f"
Subject: Re: [PHP-DEV] Experimental features
From: david.proweb@gmail.com (David Rodrigues)

--0000000000006f5fc705ea4c9b3f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thank you all for participating in this discussion!

Regarding the experimental features "disappearing" in a release, therefore,
its use is not reliable, in reality the idea is that this is the exception
of the exception (when, for example, the feature itself proves to be
extremely unfeasible for performance or generating irreparable security
flaws). It is not something as if every new idea becomes an experimental
feature, but rather, ideas that already had a good technical discussion and
the doubt was in the practical application itself, but with a great
intention of turning it native in the language, however, making it
available before time for refinement and common usage.

Regarding the code development, following the previous statement, the idea
is that the core developers work on these modifications as well, since the
idea of experimental features is for the code to become a native part of
PHP.

It's different from extensions, where the discussion is on the way to
rejection and the developer who suggested it intends to do something
practical aside, and eventually the PHP team decides to make it native (but
that's another discussion, and I believe it's already possible at the
moment, at least part of the idea).

A more practical example is the following:

In the PHP RFC we have several proposals already accepted, often before the
vote, we already have a good idea of their acceptance. But let's pay
attention to only those votes that have already been approved. Normally
these features are only applied in the next version, PHP 8.2, however, when
it is released, it may lack some refinements in this sense.

Let's take, for example, the RFC "allow null and false as stand-alone
types". This feature was voted and passed unanimously on 2022-03-27, but
PHP 8.2 is due for 2022-11-24 (as far as I know -- aka Google tells me).
However, it is a feature already developed and could very well be available
on an experimental basis, so we have time to test it on smaller or personal
projects, for example, until PHP 8.2 is available where this functionality
will be 100% refined and ready to use.

declare (experimental_allow_null_false_standalone_type =3D 1);

Another advantage in this sense is that it would be possible to have a
single development branch for PHP 8.1 (current version) and 8.2
(development version), for example, with the difference of some definitions
in the code that activate or deactivate the experimental features already
developed for the future version.

So a new intended feature can be developed in 8.1 code and marked as
experimental (and common users will be able to try them out, using them in
an experimentally explicit way), and when you start preparing for the 8.2
release, those definitions become final.

Another advantage is that a new feature can be "delayed" to a future-future
version (eg. 8.3) if it is believed not to be refined enough for the next
version's release.

All I want to say is: I would love to be able to use new PHP features ahead
of time in personal projects, without having to wait for new versions to be
released (and in the meantime, I would be able to give feedback). Just as
I'm willing to take the risk of failure, after all, these are experimental
features and shouldn't be used in production (unless you're willing to take
risks). The difference between using the in-development version of PHP 8.2
is that many servers only make this version officially available after a
few months, while smaller versions of PHP usually become available within a
few days.


Atenciosamente,
David Rodrigues


Em qua., 5 de out. de 2022 =C3=A0s 13:02, Christian Schneider <
cschneid@cschneid.com> escreveu:

> Am 05.10.2022 um 15:38 schrieb Alex Wells <autaut03@gmail.com>:
> > Advantages of experimental features over extensions:
> > - they allow changes to the parser
> > - they are universally supported (by IDE's, parsers etc) because they a=
re
> > part of a stable language release, not an unpopular/unknown extension
> > - usages of them can be found in a codebase and then analysed (unlike
> > extensions that don't have any kind of marker to denote them from regul=
ar
> > code)
> > - it's easy to implement a universal warning mechanism - for IDEs, stat=
ic
> > analysers and PHP itself to warn users about the consequences of using =
an
> > experimental feature
> > - they don't need a versioning mechanism, because they are effectively
> > always "alpha" - i.e. non-stable, so any PHP release can introduce a
> > breaking change into an experimental feature
>
> Just to maybe have a more complete picture, here are some possible
> advantages of extensions over experimental features;
> - Core developers don't have to support/maintain it (they already have a
> lot on their plate)
> - Extensions have the notion of alpha/beta/stable releases and they can
> offer different versions at the same time.
> - Having to install them manually makes it obvious that you are on your
> own if you use them in production but the notion of a stable extension is
> an indication that it is not completely reckless :-)
>
> The fact that you explicitly list always being alpha as an advantage for
> experimental features makes me wonder when I would actually use them:
> - Certainly not in production? Which limits the amount of exposure such a
> feature gets to real world usage, therefore limiting the amount of insigh=
t
> in the usefulness too.
> - A branch for a future version of your code? But the experimental featur=
e
> could disappear anytime again, do you want to rely on the feature at some
> point becoming standard?
>
> My $.02,
> - Chris
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

--0000000000006f5fc705ea4c9b3f--