Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118802
MIME-Version: 1.0
References: <CAEsg9X0YvRHHKCfFfkR3uYmzwpFps54GvmD7dCcJyXv3nwio-g@mail.gmail.com>
 <a187de08-9488-4407-9255-5bd57ee3daf6@app.fastmail.com>
In-Reply-To: <a187de08-9488-4407-9255-5bd57ee3daf6@app.fastmail.com>
Date: Tue, 11 Oct 2022 22:43:48 -0300
Message-ID: <CAEsg9X2KMAaZnSEqg+36-zZ-p49awoVeuRUnMm4PYJSGYZ--KA@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000dfd3d705eacc865d"
Subject: Re: [PHP-DEV] Feature preview (formely was: experimental features)
From: david.proweb@gmail.com (David Rodrigues)

--000000000000dfd3d705eacc865d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Nice example!

> You're saying that "public private(set)" would become available in 8.2.1
(the late-December release of 8.2), but only in files that have
"declare(asymmetric_visibility=3D1);" at the top.

Yes. In that case, I should suggest declare(preview_asymmetric_visibility =
=3D
1), just to make clear that it is using a preview feature.

> However, we could still change the syntax from "public private(set)" to
"public private:set" in 8.2.6 if we decided to; that wouldn't be considered
a BC break.  But once we get to 8.3.0, whatever the syntax is at that point
is frozen and no longer changeable, and available in all files. The
declare() is now irrelevant.

Partially. As the usage definition has not yet been decided between
private(set) vs. private:set, so this feature is not ready for preview.
Unless the idea of allowing the two syntaxes to co-exist in this feature is
acceptable (which I personally think is a bad idea).


Atenciosamente,
David Rodrigues


Em ter., 11 de out. de 2022 =C3=A0s 22:23, Larry Garfield <larry@garfieldte=
ch.com>
escreveu:

> On Tue, Oct 11, 2022, at 3:25 PM, David Rodrigues wrote:
> > In order to try to organize a little better the original purpose of the
> > discussion I started, I decided to "rename" this subject to something
> > closer to the purpose. From "experimental features" to "feature preview=
".
> >
> > Original thread: https://marc.info/?l=3Dphp-internals&m=3D1664915857115=
53
> >
> > These are my suggestions, as per the discussion that took place during
> the
> > original thread.
> >
> > (A) What are preview features:
> >
> > (A1) There are features ALREADY 100% APPROVED through the voting system
> > among the PHP team and that can already be implemented in the language
> in a
> > preview format (via PR), available to the general public through
> > minor/patch releases through "preview" markers.
> >
> > (A2) These are features that are understood to be effective for the
> > language and that will be available in a future major (eg. 9.0) or mino=
r
> > release (eg. 8.2). That is, it is not intended to be removed "at any
> time".
> >
> > (B) What are NOT preview features:
> >
> > (B1) Suggested features, even if well accepted during discussions, but
> not
> > passed the voting process as approved, even if a PR is already availabl=
e.
> >
> > (B2) Experimental features (literal), whose idea would be to test "in
> > practice" its functionality before deciding if it will be part of the
> > language or not.
> >
> > (B3) Features that may have a high risk of rejection due to performance=
,
> > security or usability issues, even if they were approved during
> > voting. That is: when in doubt, even if approved, keep it as exclusive =
to
> > the next release.
> >
> > (B4) New features approved but with pending discussion should not be
> > previewable. For example: json_validate() is approved, but the function
> > name is under discussion whether is_json_valid() or json_validate() is
> > better. In this case, it prefers to keep it out of the preview until th=
at
> > is decided.
> >
> > (C) What changes in the voting process:
> >
> > (C1) An additional voting topic to decide whether a new feature can be
> > previewed or not (i.e. basically deciding whether the feature is safe t=
o
> > test ahead of time, taking security primarily into account).
> >
> > (C2) Additionally, decide what the target version of PHP will be (eg. P=
HP
> > 8.2? 8.3? 9.0?). This helps more complex features get more preview and
> > feedback time.
> >
> > (D) Advantages:
> >
> > (D1) New features will be able to be tested before an official release
> (eg.
> > 8.2), and all issues can be resolved before this release.
> >
> > (D2) During the voting process, a feature can be developed for the next
> > version (eg. 8.2) or postponed to the next-next version (eg. 8.3), if i=
t
> > encounters difficulties, without freezing/delaying the release of versi=
on
> > 8.2, for example.
> >
> > (D3) Regular users will be able to test features in preview, without
> > installing nothing (eg. PECL), since they will be available natively in
> > PHP. Of course, with the notion of the impacts such features can have
> (like
> > needing to use markers, minimal performance issues). It is important th=
at
> > the documentation makes it clear that a particular feature is under
> > development in preview mode.
> >
> > (D4) The development team will have early feedback on these features, a=
nd
> > will be able to work on fixes with more "peace of mind" and security,
> since
> > there will be no obligation to release a patch that quickly (except for
> > security issues).
> >
> > (E) Disadvantages:
> >
> > (E1) The development team will have to pay attention to early feedback
> for
> > a feature still in preview. However, this is something that would happe=
n
> > after the final version anyway. In practice, I imagine the time used
> would
> > be equivalent.
> >
> > (E2) Once the final version is released, the language would have to
> accept
> > some markers temporarily and deprecate-notice them until it is sure tha=
t
> > users have migrated to the final version. Probably these markers should
> be
> > permanently removed at the next major or major+1.
> >
> > (E3) Users using preview features should be responsible for updating th=
e
> > code as soon as the final version becomes available.
> >
> > (F) Final considerations:
> >
> > (F1) Preview features need markers, either in the function (eg.
> > preview_json_validate() or maybe Preview\json_validate()), in new class=
es
> > (eg. Preview\XYZ::method()), in new methods (eg. XYZ::preview_method())
> or,
> > if affect the language itself, in declarations (eg. declare(preview_xyz=
 =3D
> > 1)).
> >
> > (F2) Preview features can only be removed when there is a serious
> security
> > risk to the language that is irreparable. By way of comparison, removin=
g
> a
> > preview feature is like, after releasing PHP 8.2, dropping support for
> > "readonly" as class modifier. That is, it is understood that it must be
> > thought of as something unfeasible and impossible to happen.
> >
> > (F3) Preview features can be started in PHP 8.1, for example, and made
> > final in PHP 8.2, 8.3, 8.4 or 9.0, and so on, as long as this is decide=
d
> > during the vote.
> >
> > (F4) We can try a single preview feature. Instead of thinking that
> > "features in preview" should become a default for PHP now, in a
> definitive
> > way, we can opt for a new feature approved in PHP 8.3 (currently I don'=
t
> > think there is any approved, but eventually we will), for example, and
> make
> > it available in PHP 8.2 as preview. So we test in practice whether the
> idea
> > itself will work or not (and even user adherence, with open source
> projects
> > and feedback). And if all goes well, we can make it default for PHP to
> > offer this kind of support. If something goes wrong, we can let this id=
ea
> > go.
> >
> > (F5) Preview features should generally be released in patch versions (e=
g.
> > PHP 8.1.12 to preview a PHP 8.2 feature).
> >
> >
> >
> > Atenciosamente,
> > David Rodrigues
>
> So let me use a concrete example as I'm still not completely clear here.
>
> Let's suppose, hypothetically, that the asymmetric visibility RFC passes
> on 1 December this year as a preview feature, with the current syntax
> proposed.  It's a syntax change, so polyfills are not possible and
> namespaces are irrelevant.
>
> You're saying that "public private(set)" would become available in 8.2.1
> (the late-December release of 8.2), but only in files that have
> "declare(asymmetric_visibility=3D1);" at the top.
>
> However, we could still change the syntax from "public private(set)" to
> "public private:set" in 8.2.6 if we decided to; that wouldn't be consider=
ed
> a BC break.  But once we get to 8.3.0, whatever the syntax is at that poi=
nt
> is frozen and no longer changeable, and available in all files. The
> declare() is now irrelevant.
>
> Is that how you envision it working?
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

--000000000000dfd3d705eacc865d--