Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118774
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> <CAEsg9X0DAh+Y45LUdG=aFOo4cWvmBU2Vfg48YcnsQkdh1grEdg@mail.gmail.com>
 <CALKiJKqcwkMW8Dw9Htxzt=Swkz08uY5XNEOrLq2qEsyTrJczTA@mail.gmail.com>
 <C45353A1-0666-4857-AC9F-99DA0BB90031@gmail.com> <1aa20877-3365-0ace-25d2-1cb1be8f3bcc@gmail.com>
 <55686BD4-4C67-4A4F-8BE4-BDF0149296FB@gmail.com> <a2c2c00a-9bad-77e7-0bb6-9c91f1cc250b@gmail.com>
In-Reply-To: <a2c2c00a-9bad-77e7-0bb6-9c91f1cc250b@gmail.com>
Date: Thu, 6 Oct 2022 18:40:42 -0300
Message-ID: <CAEsg9X1vRehZYk1BWME1hjq6PkZ1npA1uy4ueSJ0ak1Ynw0rCQ@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000003fa20605ea648c3f"
Subject: Re: [PHP-DEV] Experimental features
From: david.proweb@gmail.com (David Rodrigues)

--0000000000003fa20605ea648c3f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> If I start coding an application that relies on these new types, is there
a chance that they'll be removed completely, and I have to rewrite it all?

Imagine that there are users, like me, who would like to test features in
development (mainly in order to provide feedback to the development team).
It shouldn't be something a user should use for big productions, but maybe
for smaller personal projects.

This is an opportunity to make improvements to the feature for the next
release, without the risk of having to do so during it.

But keep in mind that these features are already intended for PHP, and it
is not a "feature test" or suggestion. The voting process is mandatory and
the feature must already be set to "accepted".

However, we need to separate an experimental feature into stages, much like
Node does, so these are my suggestions:

1. Closed experimental: the feature has successfully passed the approval
phase, including an available PR. However, the feature will only be
available through additional configuration in php.ini, as it can still
undergo BC changes, including its complete removal.

2. Open experimental: the feature has already been state internally by
"adventurous users" and can already be used without php.ini configurations,
however, its use in code still needs experimental markers (eg.
experimental_json_validate() or declare(experimental_*)). BC is unlikely to
happen unless the feature has issues that need to be resolved before an
official release. Removing the feature is suggested not to happen, with the
exception of very serious and irreparable issues.

3. Stable: the feature proves stable enough to be used "as is" in an
official version, but is still kept as an experimental marker until a new
official version is released. At this point, imagine that it is as if the
resource were indeed official, so it would no longer be possible to remove
it or make BC changes.

4. Available: the feature is now an official part of the language and can
be used in a major/minor version without the experimental markers. Markers
will continue to work until the next major update as an alias.

Also, if a user tries to use experimental features without being aware of
it (eg. did not activate it in php.ini or did not use declare()), an error
message should be displayed.

It also makes me rethink the time it takes for a feature to be ready to be
officially delivered. My suggestion would be at least 3 months for the 1st
and another 3 months for the 2nd stage. While the "stable" stage would last
as long as needed for the next major/minor release.

This generates less risk for new features and earlier feedback from users
willing to test it.

Atenciosamente,
David Rodrigues


Em qui., 6 de out. de 2022 =C3=A0s 17:12, Rowan Tommins <rowan.collins@gmai=
l.com>
escreveu:

> On 06/10/2022 17:41, Alex Wells wrote:
> > For example, Kotlin has recently introduced a new feature - unsigned
> integer types.
>
>
> I'm still struggling to understand what I, as a user, would do about this=
.
>
> If I start coding an application that relies on these new types, is
> there a chance that they'll be removed completely, and I have to rewrite
> it all? Is there a chance that every minor version I upgrade might
> introduce subtle changes in the behaviour of my code? Or is there just a
> chance that someone will decide the bikeshed's the wrong colour and I
> have to regex replace all my "123u" to say "u123" instead?
>
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

--0000000000003fa20605ea648c3f--