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=php-internals&m=166491585711553
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 minor
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 available.
(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 that
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 to
test ahead of time, taking security primarily into account).
(C2) Additionally, decide what the target version of PHP will be (eg. PHP
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 it
encounters difficulties, without freezing/delaying the release of version
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 that
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, and
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 happen
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 that
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 the
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 classes
(eg. Preview\XYZ::method()), in new methods (eg. XYZ::preview_method()) or,
if affect the language itself, in declarations (eg. declare(preview_xyz =
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, removing 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 decided
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 idea
go.
(F5) Preview features should generally be released in patch versions (eg.
PHP 8.1.12 to preview a PHP 8.2 feature).
Atenciosamente,
David Rodrigues
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=php-internals&m=166491585711553
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 minor
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 available.(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 that
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 to
test ahead of time, taking security primarily into account).(C2) Additionally, decide what the target version of PHP will be (eg. PHP
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 it
encounters difficulties, without freezing/delaying the release of version
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 that
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, and
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 happen
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 that
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 the
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 classes
(eg. Preview\XYZ::method()), in new methods (eg. XYZ::preview_method()) or,
if affect the language itself, in declarations (eg. declare(preview_xyz =
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, removing 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 decided
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 idea
go.(F5) Preview features should generally be released in patch versions (eg.
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=1);" 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 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.
Is that how you envision it working?
--Larry Garfield
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=1);" at the top.
Yes. In that case, I should suggest declare(preview_asymmetric_visibility =
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 às 22:23, Larry Garfield larry@garfieldtech.com
escreveu:
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=php-internals&m=166491585711553
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 minor
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 available.(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 that
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 to
test ahead of time, taking security primarily into account).(C2) Additionally, decide what the target version of PHP will be (eg. PHP
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 it
encounters difficulties, without freezing/delaying the release of version
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 that
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, and
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 happen
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 that
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 the
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 classes
(eg. Preview\XYZ::method()), in new methods (eg. XYZ::preview_method())
or,
if affect the language itself, in declarations (eg. declare(preview_xyz =
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, removing
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 decided
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 idea
go.(F5) Preview features should generally be released in patch versions (eg.
PHP 8.1.12 to preview a PHP 8.2 feature).Atenciosamente,
David RodriguesSo 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=1);" 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 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.Is that how you envision it working?
--Larry Garfield
--
To unsubscribe, visit: https://www.php.net/unsub.php
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=1);" at the top.Yes. In that case, I should suggest declare(preview_asymmetric_visibility =
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
(Please don't top post.)
Well, the syntax has been decided at this point, by the poll conducted earlier. But it was the only reasonable "otherwise BC breaking" change example I could think of. :-)
So if your proposal would not allow that hypothetical change, what would it allow?
--Larry Garfield
From what I understand, your concern is "what if we need to change the
direction of something already decided"? For example, initially it was
decided and very well accepted private(set), but after a while the idea was
revised and it was decided that private:set would be better instead.
In this case, I still believe that the ideal is that this does not change.
But we have a options to decide:
(1) Do not allow changes of this type, as private(set) was initially well
accepted and, unfortunately, nothing can be done. Perhaps, with the
exception of code conflicts that might be discovered later.
(2) Allow BC if the change is reasonable (in this example, if some sort of
code conflict is later discovered). AND:
(2.a) Keep the old syntax (private(set)) at least until the official
version is released, which will use private:set if possible.
(2.b) Keep the old syntax for at least a few releases (eg. patch+3), or a
few months (eg. 6 months) if possible.
(2.c) Consider BC permanent and users will need to change existing codes
immediately.
In particular, I believe that option (1) is ideal, or in the last case
(2.a). While option (2.c) would be easier to maintain and also acceptable,
as users using preview features will be using it at the risk of things like
this happening.
In general, the proposal is to allow new features to be tested more easily
and earlier, as long as they are ready for use and in their final version
(or very close to it). Something like a "Release Candidate" version of this
new feature.
(By top posting, you mean what gmail does by keeping the previous message
at the end of the email, right? I'll be more careful, thanks!)
On Tue, Oct 11, 2022 at 6:44 PM David Rodrigues david.proweb@gmail.com
wrote:
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).
If a "preview" doesn't allow us to make breaking changes, then what exactly
is the point? I don't see any benefit at all to this without that.
If the "preview" is actually just "put out an RFC in the next patch
release as soon as it's merged to master", which is what it seems you're
saying (as that seems like all that's left with all the things you said we
can't do in a preview), then that seems dubious, prone to instability in
the engine outside of the preview features, and a total breakage of the
release cycle and RM process that is currently in place.
Jordan
If a "preview" doesn't allow us to make breaking changes, then what exactly
is the point? I don't see any benefit at all to this without that.If the "preview" is actually just "put out an RFC in the next patch
release as soon as it's merged to master", which is what it seems you're
saying (as that seems like all that's left with all the things you said we
can't do in a preview), then that seems dubious, prone to instability in
the engine outside of the preview features, and a total breakage of the
release cycle and RM process that is currently in place.
100% agree. Kotlin's experimental features are drastically different from what was described by David. I don't think "feature previews" deliver any value to PHP's development process here; mainly, it doesn't allow breaking changes, thus not allowing developers to be at ease when accepting features due to knowing they could make changes as they go, which I see as the main benefit.
It would have helped deliver features which were otherwise declined due to someone not liking the syntax, not seeing the usefulness or just not convinced. If a feature is proven to not be a good fit for PHP then it's removed.
Feature previews as I see it solve exactly one problem: feature's runtime stability - but I don't think this is a problem of PHP in the first place.
As I previously wrote in the old Thread, ...
I would like to say that we should keep the release process as it is,
until a true, real, use case shows up.
Whoever participated in the threads is already aware about the so many
possibilities, and adjustments to the release/work process , that have
to be done; because of that, such work should be at least justified
with a real case.
The actual release process is consistent, secure, predictable, not
perfect ... sure, but to justify such a radical change, I believe we
should have a real use case.