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 have
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 quite
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 =
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() or
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 the
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 try
them out more easily.
Atenciosamente,
David Rodrigues
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 have
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 quite
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 =
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() or
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 the
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 try
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.
sounds like that's been done with PECL previously yeah?
PECL json until native json_encode in PHP5.2.0,
PECL PDO until native PDO in PHP 5.1.0,
PECL ZendOpcache until native opcache in PHP 5.5.5
etc?
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 have
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 quite
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 =
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() or
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 the
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 try
them out more easily.Atenciosamente,
David RodriguesHi 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.
Hi Flávio 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 às 19:37, Flávio Heleno flaviohbatista@gmail.com
escreveu:
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 have
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 quite
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 =
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() or
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 the
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 try
them out more easily.Atenciosamente,
David RodriguesHi 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.
My small contribution to this ....
First of all, nice you picked "json_validate()" for your example,
thanks for this, somehow, support! :)
Second...
Apply a PECL strategy to try experimental features might not be the
convenient way always, for example, if we create a new ... sensitive
... ini setting that affects the behavior of PHP somehow, then ...
maybe applying the PECL strategy might not be the most confortable way
to approach it, OR ... what about a new sensitive funtion in a "core
extension" like JSON?
An Experimental feature is something that WE want it to be in such a
way because we want to see how the feature behaves, and what can of
feedback can we get out of it.
In case this proposal is accepted, it will change the RFC process for
sure in order to indicate if its experimental or not.
I think Experimental features , no matther what they are, should be
backup with a consistent monitoring strategy around them.... something
to keep in mind; This proposal is more about workflows in the PHP
project than something else.
On Wed, Oct 5, 2022, 7:54 AM juan carlos morales dev.juan.morales@gmail.com
wrote:
Apply a PECL strategy to try experimental features might not be the
convenient way always, for example, if we create a new ... sensitive
... ini setting that affects the behavior of PHP somehow, then ...
maybe applying the PECL strategy might not be the most confortable way
to approach it, OR ... what about a new sensitive funtion in a "core
extension" like JSON?
Just to build up on this. I feel like Extensions are maybe a technical /
development feature that may have the power to address the issue, but from
a "Product" (PHP language as the product) this isn't the best. Anything
behind extensions add a significant entry burden and reduce the reach for
users of the product, be it for lack of trust, knowledge or lack of
infrastructure that allows such changes.
On Wed, Oct 5, 2022, 7:54 AM juan carlos morales <
dev.juan.morales@gmail.com>
wrote:Apply a PECL strategy to try experimental features might not be the
convenient way always, for example, if we create a new ... sensitive
... ini setting that affects the behavior of PHP somehow, then ...
maybe applying the PECL strategy might not be the most confortable way
to approach it, OR ... what about a new sensitive funtion in a "core
extension" like JSON?Just to build up on this. I feel like Extensions are maybe a technical /
development feature that may have the power to address the issue, but from
a "Product" (PHP language as the product) this isn't the best. Anything
behind extensions add a significant entry burden and reduce the reach for
users of the product, be it for lack of trust, knowledge or lack of
infrastructure that allows such changes.
Deleu & Juan,
Thanks for clearing this up!
A product approach could be something interesting to explore. I'm more than
happy to join and help anyway I can.
--
Atenciosamente,
Flávio Heleno
Hey.
Experimental features have been briefly discussed before in
https://github.com/PHPGenerics/php-generics-rfc/issues/49. I believe this
is a good starting point to understand how it's different to extensions or
otherwise different builds of PHP.
Advantages of experimental features over extensions:
- they allow changes to the parser
- they are universally supported (by IDE's, parsers etc) because they are
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 regular
code) - it's easy to implement a universal warning mechanism - for IDEs, static
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
On Wed, Oct 5, 2022 at 1:38 AM Flávio Heleno flaviohbatista@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 have
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 quite
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 =
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() or
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
the
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 try
them out more easily.Atenciosamente,
David RodriguesHi 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.
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 are
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 regular
code)- it's easy to implement a universal warning mechanism - for IDEs, static
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 insight in the usefulness too.
- A branch for a future version of your code? But the experimental feature could disappear anytime again, do you want to rely on the feature at some point becoming standard?
My $.02,
- Chris
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 = 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 às 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 are
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 regular
code)- it's easy to implement a universal warning mechanism - for IDEs, static
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 featureJust 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 insight
in the usefulness too.- A branch for a future version of your code? But the experimental feature
could disappear anytime again, do you want to rely on the feature at some
point becoming standard?My $.02,
- Chris
--
To unsubscribe, visit: https://www.php.net/unsub.php
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.
The problem I predict with this is that unless they have a convenient "hook
point", experimental features would lead to ugly code: they need to be
enabled at run-time rather than build-time, so are hard to optimise; and
they are going to be released after a short test cycle, so need to avoid
refactoring.
Maybe there are enough "hook points" in the engine that some categories of
feature could be implemented without too much disruption, but it's a
complex beast with a shortage of experts, so I'm wary of adding more
complexity.
I also agree with the previous comment that this would need to be coupled
with some way of monitoring the results - imagine we released an
experimental feature 3 months ago, what do we do exactly to find out if it
needs changing?
Regards,
Rowan Tommins
[IMSoP]
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.The problem I predict with this is that unless they have a convenient "hook
point", experimental features would lead to ugly code: they need to be
enabled at run-time rather than build-time, so are hard to optimise; and
they are going to be released after a short test cycle, so need to avoid
refactoring.Maybe there are enough "hook points" in the engine that some categories of
feature could be implemented without too much disruption, but it's a
complex beast with a shortage of experts, so I'm wary of adding more
complexity.I also agree with the previous comment that this would need to be coupled
with some way of monitoring the results - imagine we released an
experimental feature 3 months ago, what do we do exactly to find out if it
needs changing?Regards,
Rowan Tommins
[IMSoP]
A marker merely just tells the compiler "hey, allow me to use this feature right here", i.e. it denotes a piece of code as allowed to use the feature, not enable it. Effectively, all experimental features are just regular features that are "always on" and hence can be optimized the same way regular features are. The marker serves two purposes: allow simple discovery of usages (by the compiler or other tools) and force the developer to acknowledge they're using an experimental feature with an unstable API/syntax/spec.
Regarding the monitoring - that is a problem that needs to be solved and there are multiple solutions: GitHub issues, corporate/public messengers (Slack?) or the internals mailing list.
A marker merely just tells the compiler "hey, allow me to use this feature right here", i.e. it denotes a piece of code as allowed to use the feature, not enable it. Effectively, all experimental features are just regular features that are "always on" and hence can be optimized the same way regular features are. The marker serves two purposes: allow simple discovery of usages (by the compiler or other tools) and force the developer to acknowledge they're using an experimental feature with an unstable API/syntax/spec.
I don't really understand the distinction between "enabling" and "being
able to use", nor what it would mean for a feature to "experimental" but
also integrated fully into the language.
In general, I'm finding it quite hard to follow the idea in the abstract
- the definition of "feature" seems very fuzzy. Could someone give some
examples from another language, or concrete examples where it would be
used in PHP, and then work through the details of what would be expected
to happen in what version of PHP?
Regarding the monitoring - that is a problem that needs to be solved and there are multiple solutions: GitHub issues, corporate/public messengers (Slack?) or the internals mailing list.
There are certainly ways to approach it; I'm just agreeing with a
previous commenter that this would need to be an explicit part of any
proposal, not just hand-waved away.
Regards,
--
Rowan Tommins
[IMSoP]
A marker merely just tells the compiler "hey, allow me to use this feature right here", i.e. it denotes a piece of code as allowed to use the feature, not enable it. Effectively, all experimental features are just regular features that are "always on" and hence can be optimized the same way regular features are. The marker serves two purposes: allow simple discovery of usages (by the compiler or other tools) and force the developer to acknowledge they're using an experimental feature with an unstable API/syntax/spec.
I don't really understand the distinction between "enabling" and "being able to use", nor what it would mean for a feature to "experimental" but also integrated fully into the language.
In general, I'm finding it quite hard to follow the idea in the abstract - the definition of "feature" seems very fuzzy. Could someone give some examples from another language, or concrete examples where it would be used in PHP, and then work through the details of what would be expected to happen in what version of PHP?
Regarding the monitoring - that is a problem that needs to be solved and there are multiple solutions: GitHub issues, corporate/public messengers (Slack?) or the internals mailing list.
There are certainly ways to approach it; I'm just agreeing with a previous commenter that this would need to be an explicit part of any proposal, not just hand-waved away.
Regards,
--
Rowan Tommins
[IMSoP]--
To unsubscribe, visit: https://www.php.net/unsub.php
I'll try my best to elaborate, although I the author of the proposal will likely do a better job.
A feature is generally considered any addition to the language or it's standard library - that could be a new set of functions, new syntax etc. Experimental features refer to features whose stability is "experimental".
Kotlin divides their features into four stability levels: experimental, alpha, beta and stable. Each of those might have their own preconditions, BC promises and release cycle rules. A feature with "experimental" stability level requires an opt-in: a piece of code that uses the new feature must be marked with an annotation. For example, Kotlin has recently introduced a new feature - unsigned integer types. This inlcudes new types and a new syntax. This is how you'd use them:
@OptIn(ExperimentalUnsignedTypes::class)
fun unsignedInt(): UInt {
return 123u
}
@OptIn(ExperimentalUnsignedTypes::class)
fun main(args: Array<String>) {
println(
unsignedInt()
)
}
123u here denotes an integer that is unsigned. The u part is the new syntax. UInt is the new type. Notice two OptIn annotations - one for the function which returns the new type, and the other for it's dependent. The second annotation is needed because of the return type - Kotlin assumes the return type is used, effectively assuming you're using the new type in your function, which requires opt-in.
This changes if unsignedInt returns Int (a regular type, not part of the experimental feature) instead:
@OptIn(ExperimentalUnsignedTypes::class)
fun unsignedInt(): Int {
return 123u as Int // cast UInt to Int
}
fun main(args: Array<String>) {
println(
unsignedInt()
)
}
Notice how an opt-in is no longer needed for main.
If you omit the opt-in altogether, this is what the compiler (and the IDE) will throw at you: Main.kt: (7, 20): This declaration is experimental and its usage should be marked with '@kotlin.ExperimentalUnsignedTypes' or '@OptIn(kotlin.ExperimentalUnsignedTypes::class)'
Of course, in Kotlin there also mechanism to opt-in more than just a single function. This can be done on file, module or even project level:
@file:OptIn(ExperimentalUnsignedTypes::class)
// or module-wide
sourceSets {
someModule {
languageSettings.optIn("org.mylibrary.OptInAnnotation")
}
}
// or project-wide compiler flag
-opt-in=org.mylibrary.OptInAnnotation
////
Onto the PHP application. It's similar, although obviously due to the dynamic nature of the language the compiler wouldn't be able to force opt-ins nearly on the same level as Kotlin compiler does. This isn't to say experimental features can't be implemented properly in PHP.
Let's say PHP wants to experiment with a new function - json_validate(). The idea is simple: follow the regular RFC process and release the function the same way you would without experimental functions. The only thing that is needed is to mark the function as one that requires an opt-in:
#[Experimental(ExperimentalLevel.WARNING)]
class ExperimentalJsonValidate {}
#[RequiresOptIn(ExperimentalJsonValidate::class)]
function json_validate($something): something {}
Then, any consumer of that function would be required to opt-in:
#[OptIn(ExperimentalJsonValidate::class)]
function main() {
json_validate(); // all good
}
If an opt-in is missing, PHP will trigger an warning (during runtime):
function main() {
json_validate(); // trigger_error('Must be opted-in', E_WARNING)
}
Few months after the release (let's say 8.2), PHP collects feedback and analyses codebases (which is easy thanks to the attribute) and decides it wants to change the name to json_revalidate. This is of course over exaggerated, but it's to prove the point. Just as any other change in PHP, this would require an RFC. If it's accepted, the change is done.
Under regular circumstances (no experimental features), such a change would have to at least have a deprecation notice for one minor/major release prior to it (so the minimum version this could be done in is 8.4). Moreover, such changes would usually be avoided at all costs, because this is a big breaking change.
Experimental features on the other hand are explicit opt-in - users know it can be changed at any time, without a warning, a deprecation or anything for that matter, in any release. That allows the change to be done without really worrying of BC and also much earlier (8.3 or even 8.2.1 if you decide so). Also, the #OptIn attribute allows consumers to easily find all places where an experimental feature was used in case a breaking change was done.
The same concept can also be applied to new syntax - let's say generics, except with a more strict error (E_FATAL, for example). This has been briefly discussed here: https://github.com/PHPGenerics/php-generics-rfc/issues/49
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]
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]--
To unsubscribe, visit: https://www.php.net/unsub.php
Yes to all. There's a chance for anything to happen with an experimental feature any time.
This of course doesn't mean it has to happen; actually, it barely ever happens. It's not like Kotlin ships features without thinking them through - it's just that they have that fallback to introduce a breaking change without any additional hassles (like deprecations or keeping a backwards-compatibility promise) if they want it.
Allowing breaking changes in patch releases in Kotlin does sound reasonable - at the very least most breaking changes will get caught on compilation stage.
This won't happen with PHP, so we're likely better off still limiting any breaking changes to minor/major releases. Yet we're still winning in a sense that there won't be any deprecations needed (which not only saves a lot of time, but also simplifies the process a lot) and will have a safe window to change the API altogether when problems arise.
You as a user act as an alpha-tester of language's feature, with all the related pros and cons. You get access to all the newest and shiniest, but you have to always keep track of PHP's changelog (much more than "regular" users) and be prepared to act upon breaking changes (again, possibly a lot more than regular users).
On Thu, Oct 6, 2022 at 1:12 PM Rowan Tommins rowan.collins@gmail.com
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?
I would think all of the above, though I would expect given the nature of
the RFC process that it would be exceedingly rare in PHP. It would be like
a release preview only in a stable version. It does seem like it would have
utility in PHP, since we could introduce a feature without worrying about
BC breaks if it needs to be modified and adjusted.
Jordan
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:
-
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. -
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. -
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. -
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 às 17:12, Rowan Tommins rowan.collins@gmail.com
escreveu:
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]--
To unsubscribe, visit: https://www.php.net/unsub.php
Am 06.10.2022 um 23:40 schrieb David Rodrigues david.proweb@gmail.com:
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".
Just so I understand what you are saying: You would only add things to experimental where an RFC for it has been accepted?
What you basically want to do is to introduce such features into the current stable branch instead of the upcoming one, right?
However, we need to separate an experimental feature into stages, much like
Node does, so these are my suggestions:
[...]
- 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.
One side-note here: I would strongly advise not to use an experimental_ prefix or package for functions because it would be a PITA to make code compatible with different versions, one where the function has the experimental_ prefix / package and one where it doesn't.
But now to my main point: You are talking about the most simple and isolated case, a new function.
Your model may work fine with that but as soon as we are talking something like a syntax change we have some additional problems:
- Enabling it with a prefix obviously does not work, something like declare() is definitely needed
- Maintaining such changes to the engine / parser could turn out messy, e.g. lots of "if (experimental_x)"-like code in the core
- The test suite would possibly have to deal with an exponential explosion of experimental feature combinations to make sure they don't interfere with each other.
All in all I'm not sold yet that the benefit outweighs the cost of this approach.
Regards,
- Chris
On Fri, 7 Oct 2022 at 07:57, Christian Schneider cschneid@cschneid.com
wrote:
But now to my main point: You are talking about the most simple and
isolated case, a new function.
I agree, and for most intent and purposes a function can be polyfilled in
userland. So this is the least interesting case.
However, I don't think this approach is that useful. To give an example,
for DNF types the implementation is based on a change in how iterable works
in PHP.
It went from a pseudo-type to a compile time alias, as this massively
simplified variance and LSP checks.
I would not want such a change to land in a patch release especially as it
turned out there was an unintended BC break with the compile time
redundancy which only got fixed in PHP8.2RC2.
Your model may work fine with that but as soon as we are talking something
like a syntax change we have some additional problems:
- Enabling it with a prefix obviously does not work, something like
declare() is definitely needed- Maintaining such changes to the engine / parser could turn out messy,
e.g. lots of "if (experimental_x)"-like code in the core- The test suite would possibly have to deal with an exponential explosion
of experimental feature combinations to make sure they don't interfere with
each other.All in all I'm not sold yet that the benefit outweighs the cost of this
approach.
Ditto.
When Nikita proposes editions back in 2020 (
https://github.com/nikic/php-rfcs/blob/language-evolution/rfcs/0000-language-evolution.md)
the point about them was mainly about backwards-incompatible changes, not
new features.
Because in general new features don't have the same issues, especially
since the RFC process (although not without its issues) does force thinking
about the design of it instead of just shoving something in php-src
randomly as in the before days.
Best regards,
George P. Banyard
On Fri, 7 Oct 2022 at 07:57, Christian Schneider cschneid@cschneid.com
wrote:But now to my main point: You are talking about the most simple and
isolated case, a new function.I agree, and for most intent and purposes a function can be polyfilled in
userland. So this is the least interesting case.However, I don't think this approach is that useful. To give an example,
for DNF types the implementation is based on a change in how iterable works
in PHP.
It went from a pseudo-type to a compile time alias, as this massively
simplified variance and LSP checks.
I would not want such a change to land in a patch release especially as it
turned out there was an unintended BC break with the compile time
redundancy which only got fixed in PHP8.2RC2.Your model may work fine with that but as soon as we are talking something
like a syntax change we have some additional problems:
- Enabling it with a prefix obviously does not work, something like
declare() is definitely needed- Maintaining such changes to the engine / parser could turn out messy,
e.g. lots of "if (experimental_x)"-like code in the core- The test suite would possibly have to deal with an exponential explosion
of experimental feature combinations to make sure they don't interfere with
each other.All in all I'm not sold yet that the benefit outweighs the cost of this
approach.Ditto.
When Nikita proposes editions back in 2020 (
https://github.com/nikic/php-rfcs/blob/language-evolution/rfcs/0000-language-evolution.md)
the point about them was mainly about backwards-incompatible changes,
not
new features.
Because in general new features don't have the same issues, especially
since the RFC process (although not without its issues) does force
thinking
about the design of it instead of just shoving something in php-src
randomly as in the before days.Best regards,
George P. Banyard
I think what would be useful here to better understand the value, if any, would be to look back at some recent RFCs, both those that passed and those that didn't, and imagine how they would have gone had there been an "experimental" flag option for them.
Would they have been marked experimental at all? Why?
What might have changed and when while in experimental phase?
When would they have been removed instead of being adjusted?
Etc.
Some candidates to consider could be:
- Named args
- PIpes
- PFA
- Intersection types
- Enums
- JIT
- FFI
Personally I'm still highly skeptical that this would be useful, or useful enough to justify the engine complexity.
Bear in mind that browsers had "experimental" CSS features for a while, and eventually abandoned prefixing as it was an absolute mess as the experimental features ended up in production and then had to be supported forever in that early, broken form. Instead, they switched to an opt-in flag in browser configuration (~php.ini setting) on the assumption that devs could play with it, but it was completely impractical to ship to production so no one did, so they could still change it. Experimental features never leave the dev's own computer until they are no longer experimental. That has worked out a lot better.
We should learn from that experience.
--Larry Garfield
On Fri, 7 Oct 2022 at 07:57, Christian Schneider cschneid@cschneid.com
wrote:But now to my main point: You are talking about the most simple and
isolated case, a new function.I agree, and for most intent and purposes a function can be polyfilled in
userland. So this is the least interesting case.However, I don't think this approach is that useful. To give an example,
for DNF types the implementation is based on a change in how iterable works
in PHP.
It went from a pseudo-type to a compile time alias, as this massively
simplified variance and LSP checks.
I would not want such a change to land in a patch release especially as it
turned out there was an unintended BC break with the compile time
redundancy which only got fixed in PHP8.2RC2.Your model may work fine with that but as soon as we are talking something
like a syntax change we have some additional problems:
- Enabling it with a prefix obviously does not work, something like
declare() is definitely needed- Maintaining such changes to the engine / parser could turn out messy,
e.g. lots of "if (experimental_x)"-like code in the core- The test suite would possibly have to deal with an exponential explosion
of experimental feature combinations to make sure they don't interfere with
each other.All in all I'm not sold yet that the benefit outweighs the cost of this
approach.Ditto.
When Nikita proposes editions back in 2020 (
https://github.com/nikic/php-rfcs/blob/language-evolution/rfcs/0000-language-evolution.md)
the point about them was mainly about backwards-incompatible changes,
not
new features.
Because in general new features don't have the same issues, especially
since the RFC process (although not without its issues) does force
thinking
about the design of it instead of just shoving something in php-src
randomly as in the before days.Best regards,
George P. Banyard
I think what would be useful here to better understand the value, if any, would be to look back at some recent RFCs, both those that passed and those that didn't, and imagine how they would have gone had there been an "experimental" flag option for them.
Would they have been marked experimental at all? Why?
What might have changed and when while in experimental phase?
When would they have been removed instead of being adjusted?
Etc.Some candidates to consider could be:
- Named args
- PIpes
- PFA
- Intersection types
- Enums
- JIT
- FFI
Personally I'm still highly skeptical that this would be useful, or useful enough to justify the engine complexity.
Bear in mind that browsers had "experimental" CSS features for a while, and eventually abandoned prefixing as it was an absolute mess as the experimental features ended up in production and then had to be supported forever in that early, broken form. Instead, they switched to an opt-in flag in browser configuration (~php.ini setting) on the assumption that devs could play with it, but it was completely impractical to ship to production so no one did, so they could still change it. Experimental features never leave the dev's own computer until they are no longer experimental. That has worked out a lot better.
We should learn from that experience.
--Larry Garfield
--
To unsubscribe, visit: https://www.php.net/unsub.php
I don't think it's valid to compare browser (client side) and PHP (server side): browser versions and support is not controlled by the server, so it's not fair to expect client-side experimental features to perform as good as server-side ones. If there's anyone to learn from, it should be Kotlin or other server languages.
Would they have been marked experimental at all? Why?
What might have changed and when while in experimental phase?
When would they have been removed instead of being adjusted?
Etc.
That's an interesting thought experiment. Here are the thoughts that
occur to me:
Some candidates to consider could be:
- Named args
Possibly an experimental phase would have given more time for the names
of arguments on internal functions to be decided. Some third-party
libraries might also have taken advantage of that timescale, although
some would still have decided to simply say names are not guaranteed to
be stable.
- Pipes
- PFA
If experimental features had a lower voting threshold, perhaps these
would have been accepted at that stage; but I'm not sure what would
happen during that phase that would prevent them being rejected as a
permanent feature.
- Intersection types
Anything that leads to complex changes in the engine can realistically
only be released in an annual .0 release, because the alpha & beta
period is essential to spot regressions to existing functionality. That
means an experimental flag will only ever mean waiting longer to use
such features in production, not getting them sooner.
The only benefit would therefore be if there are behaviour details that
are "locked in" which could have been changed if they were marked
experimental; I'm not aware of any in this case, but it does happen -
the discussions around readonly classes and inheritance come close,
although allowing something that was previously forbidden at
compile-time is generally not considered a BC break anyway.
- JIT
This is already behind a run-time flag, and exposes very little direct
API, so an "experimental" release would mostly be a question of
documentation (on php.net, and in the shipped sample ini files), and the
compiled-in default for the flag. That wouldn't have needed any new policy.
- FFI
This does include a user-facing API, and that API has a few rough
edges. However, it was developed entirely as an extension, and we
already have a mechanism for marking those experimental: ship them in
PECL first, and allow breaking changes while bundling into the main
source tree. This happened with ext/sodium for instance. Why it didn't
happen with FFI, I'm not entirely sure.
The same might go for Fibers, although delivery as an extension would
probably require a different implementation from what we have. I'm not
sure it would have made sense to ship it in a state that made changes to
the engine, requiring changes to other extensions to be compatible, but
then make users wait before using it in production.
Regards,
--
Rowan Tommins
[IMSoP]
Hi,
in my every day experience, using custom DTO classes and different API,
I often write code to instantiate my objects from associative arrays.
What are your thoughts on introduce the (AnyType) cast to instantiate
objects from associative array (or object properties also)?
In my proposal, if AnyType implements __set_state(), casting should be
syntactic sugar for:
AnyType::_set_state((array) $data)
just for (useless) example, consider DateTime or DateTimeImmutable (both
have __set_state() implementation); when applied to objects of that
type, we can write:
$dt = new DateTime();
$dtArray = (array) $dt; // 3 elements array
$copyOfDt = (DateTime) $dtArray; // or simply $copyOfDt =
(DateTime) $dt;
In case AnyType does not implements __set_state(), casting should create
a new instance, assigning values to properties, taken from array values
with corresponding key (in a similar way class objects are created when
row is fetched from database specifying PDO_FETCH_CLASS) eventually
invoking __set() magic method for properties not declared;
In this scenario,
(object) ['one' => 1, 'two' => 2]
and
(StdClass) ['one' => 1, 'two' => 2]
do exactly the same work.
Reasons:
-
clear code
-
array to object conversion (casting) would be the simmetrical
counterpart of object to array conversion
Thanks,
Gianni
On Sat, 15 Oct 2022 at 13:14, Gianni Gentile
g.gentile@parentesigraffe.com wrote:
What are your thoughts on introduce the
(AnyType)cast to instantiate
objects from associative array (or object properties also)?
It seems a pretty bad idea.
In particular, it makes for hard to maintain code as it doesn't give a
place for error checking to occur.
Though I do actually use that pattern in code. Below is a trait that
accomplishes it that should only be used in prototype code. Having it
as a trait means at least I can debug through the initialization and
see if it's missing properties from the array,
But in general, you'd really need to make a strong argument for why it
should be in core, not just why anyone would be against it.
cheers
Dan
Ack
trait FromArray
{
/**
* @param array $data
* @return static
* @throws \ReflectionException
*/
public static function fromArray(array $data): self
{
$reflection = new \ReflectionClass(CLASS);
$instance = $reflection->newInstanceWithoutConstructor();
foreach ($instance as $key => &$property) {
$property = $data[$key];
}
return $instance;
}
}
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 have
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 quite
polished, avoiding patches sometime later due to wider usage of users.
Do the other platforms introduce experimental features in revisions? I
doubt that, and I'm pretty sure that is (at least currently) no option
for PHP. We have several months of bi-weekly pre-releases for new
minor/major versions, and are barely able to stabilize new features; not
only wrt. to the feature itself, but also wrt. unforeseen side effects.
The current release cycle[1] still mostly makes sense to me, and that
says for revisions:
- Bugfixes only (with a room for exceptions on a case by case basis and
only for small self contained features additions)
I wouldn't want to sacrifice stability in favor of shipping new features
every month – including having more discussions about which feature may
be introduced in a revision.
[1] https://wiki.php.net/rfc/releaseprocess#releases_cycle
--
Christoph M. Becker
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 have
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 quite
polished, avoiding patches sometime later due to wider usage of users.Do the other platforms introduce experimental features in revisions? I
doubt that, and I'm pretty sure that is (at least currently) no option
for PHP. We have several months of bi-weekly pre-releases for new
minor/major versions, and are barely able to stabilize new features; not
only wrt. to the feature itself, but also wrt. unforeseen side effects.The current release cycle[1] still mostly makes sense to me, and that
says for revisions:
- Bugfixes only (with a room for exceptions on a case by case basis and
only for small self contained features additions)I wouldn't want to sacrifice stability in favor of shipping new features
every month – including having more discussions about which feature may
be introduced in a revision.[1] https://wiki.php.net/rfc/releaseprocess#releases_cycle
--
Christoph M. Becker--
To unsubscribe, visit: https://www.php.net/unsub.php
Speaking of Kotlin, there are no rules regarding experimental features. This is because they extensively use their "opt-in" API, which allows them to mark even a single function/method as experimental. It doesn't make sense to wait a minor release for a year to introduce a single new function.
Of course, any medium-large size features are kept to minor/major releases.
My two cents...
Why can't "common users" install a PECL extension? It's not a difficult,
obscure or undocumented process.
I can accept the reasoning
Apply a PECL strategy to try experimental features might not be the
convenient way always, for example, if we create a new ... sensitive ini
setting that affects the behavior of PHP somehow... OR ... what about a new
sensitive funtion in a "core extension" like JSON?
But why would the answer in those cases not be "compile the PHP fork/branch
with the experimental feature", rather than find a way to flag the engine
to switch arbitrary new features on or off, complete with all the
complications in the primary source code that would cause? We are, after
all, talking about features which by definition should not be relied upon
for any production use.
Or we're talking about features which are stable and valuable enough to
have passed an RFC process, but then what's gained from an experimental
designation? Why couldn't they just be included in a preview/beta/RC
version which anyone could decide to run or not?
The idea is that the experimental features are exclusively something that
the PHP team has voted for (approved) and that will be part of the language.
Users can choose to install PECL, but it is not the same, because it
depends on other users (who can make use of this code) having the notion
that a certain PECL will be necessary.
Imagine a package under development (eg. Laravel 10) that is (supposing
that) intended to be released compatible with PHP 8.3 (supposing that it
already has experimental features). In this case, the Laravel team can
start using an experimental feature while developing Laravel 10, waiting
for the release of PHP 8.3. Once the PHP 8.3 release is finished, Laravel
10 can just remove the experimental tags and release its new version fastly.
The user, on condition that he is willing to use Laravel 10 (in
development) will make indirect use of experimental features. Then both the
Laravel team and these users will be able to provide feedback for these
features to the PHP team before the official release.
Like json_validate(): assuming Laravel needs to check if a code is valid
JSON, but without processing its data for use. It could check if PHP >=
8.3, so use experimental_json_validate(), else use previous PHP compatible
code.
Atenciosamente,
David Rodrigues
Em seg., 10 de out. de 2022 às 19:20, David Gebler davidgebler@gmail.com
escreveu:
My two cents...
Why can't "common users" install a PECL extension? It's not a difficult,
obscure or undocumented process.I can accept the reasoning
Apply a PECL strategy to try experimental features might not be the
convenient way always, for example, if we create a new ... sensitive ini
setting that affects the behavior of PHP somehow... OR ... what about a new
sensitive funtion in a "core extension" like JSON?But why would the answer in those cases not be "compile the PHP
fork/branch with the experimental feature", rather than find a way to flag
the engine to switch arbitrary new features on or off, complete with all
the complications in the primary source code that would cause? We are,
after all, talking about features which by definition should not be relied
upon for any production use.Or we're talking about features which are stable and valuable enough to
have passed an RFC process, but then what's gained from an experimental
designation? Why couldn't they just be included in a preview/beta/RC
version which anyone could decide to run or not?
On Tue, Oct 11, 2022 at 12:05 AM David Rodrigues david.proweb@gmail.com
wrote:
The idea is that the experimental features are exclusively something that
the PHP team has voted for (approved) and that will be part of the language.
So they're not experimental features, they're accepted RFCs, maybe with a
lower voting threshold.
Imagine a package under development (eg. Laravel 10) that is (supposing
that) intended to be released compatible with PHP 8.3 (supposing that it
already has experimental features). In this case, the Laravel team can
start using an experimental feature while developing Laravel 10, waiting
for the release of PHP 8.3. Once the PHP 8.3 release is finished, Laravel
10 can just remove the experimental tags and release its new version fastly.The user, on condition that he is willing to use Laravel 10 (in
development) will make indirect use of experimental features. Then both the
Laravel team and these users will be able to provide feedback for these
features to the PHP team before the official release.Like json_validate(): assuming Laravel needs to check if a code is valid
JSON, but without processing its data for use. It could check if PHP >=
8.3, so use experimental_json_validate(), else use previous PHP compatible
code.
This is what's bothering me. Either these "experimental" features have
passed RFC and will be part of the language, as you've said above, or
they're actually experimental i.e. not finalized and implementing behaviour
and syntax which may be subject to change or even dropped entirely
depending on the feedback cycle. In which case, they cannot be relied on by
developers of vendor packages or their users in the manner you suggest.
Using the trivial json_validate() example (although as others have said, a
simple new function is probably a bad example), either this function will
be part of PHP 8.3, with the exact behaviour, parameters and return type
which is known and documented, or it's experimental and might change.
If it's the former, the library can just check if PHP >= 8.3 and fall back
to userland implementation / polyfill for earlier versions. This is just
what we have now, where approved new features are part of a versioned
release.
If it's the latter, everyone touching the experimental version, directly or
indirectly, may have to rip out and change code later which renders the
work they've put in to use the experimental feature in their code pointless.
And it's not just how these things may or may not be used by users of the
language, it's how building out this system affects the clarity and
maintainability of php-src, which is esoteric enough as it is.
I can appreciate and support specific individual new, accepted features
which may not be 100% stable having a toggle in the configuration, but I'm
not convinced on the justification for a broader system of introducing
unstable features which are toggled at the syntax level.
A lot of developers (most?) who build PHP applications run them in
shared-hosted or managed hosted servers where are never given the option to
install a PECL extension.
In the rare cases they can install PECL many of those PHP developers would
not have the skills to do it or the requisite permissions on the server; I
certainly did not for the first ~10 years of working with PHP. I do now,
but ironically because I have mostly moved away from programming in PHP to
do more DevOps work.
Further, when working in multiple environments having to set up each
server to have all the same PECL installations can be just too much hurdle
so that developers won't even try, especially when working in managed
environments.
I'm inclined to suggest if you opt in to an experimental language feature,
you are by definition making at least an implicit declaration that you know
what you're doing, so the idea people using these features wouldn't have
the skills to spin up a container or install something on a VM doesn't
convince me, personally.
On Tue, Oct 11, 2022 at 12:05 AM David Rodrigues david.proweb@gmail.com
wrote:The idea is that the experimental features are exclusively something that
the PHP team has voted for (approved) and that will be part of the
language.So they're not experimental features, they're accepted RFCs, maybe with a
lower voting threshold.
I don't really see what the confusion is about. It's for features that we
have all agreed to include, but that the public API or behavior might
change in minor versions while usage information, feedback, and so-on
happens. The idea behind an experimental inclusion would be something like
"the concept behind this feature we've agreed to include, unless something
truly drastic comes up once it's out in the wild, but the syntax,
parameters, and signatures might change while we look at usage and
real-world code.
It's like the opposite of a Deprecation notice in my mind... it's a flag on
specific code that lets people know ahead of time that BC breaks in a
minor version might be necessary for this feature for a little while.
Jordan
Hi all,
I'm still not convinced everyone on this thread is actually talking
about the same idea.
For instance, on whether an experimental feature would require the same
consensus as a non-experimental one:
If there were an RFC for Experimental Use then the people on the fence could choose to allow it to see how it plays out in real-world userland cases, and a few people against it might be convinced to allow people to evaluate it, and then later make a decision on a "Forever RFC."
I don't really see what the confusion is about. It's for features that we
have all agreed to include, but that the public API or behavior might
change in minor versions while usage information, feedback, and so-on
happens.
Similarly, some are talking about getting features to users sooner, but
others about leaving it experimental for as long as it takes, which
means it gets to production later than if it was tested in the
existing alpha/beta cycle.
I think it would be really helpful to have some concrete examples,
either from other languages, or of a hypothetical feature that you think
would be a good use case clarifying:
- How it would be accepted as experimental - would it require the same
voting threshold etc as a "stable" feature? - When would it be released - in PHP terms, if it was voted on in April
this year, would it have gone into 8.1.5 or waited until 8.2.0? - What is the process for changes? Would they require votes? Would they
go into point releases like 8.1.9 or 8.2.5, or wait until 8.3.0? - What is the process for marking stable? Would it require another vote?
What version would that go into?
I'm not saying we have to have final answers to these questions, but it
would be helpful to understand people's gut feeling on them, to get a
better idea of what people are imagining.
Regards,
--
Rowan Tommins
[IMSoP]
This is what's bothering me. Either these "experimental" features have
passed RFC and will be part of the language, as you've said above, or
they're actually experimental i.e. not finalized and implementing behaviour
and syntax which may be subject to change or even dropped entirely
depending on the feedback cycle.
If they are not experimental and their usage is finalized, then they are in-fact approved and they would be absolutely no different from the existing RFCs today.
You cannot have experimental features unless those features have the potential to not be included in the future language and/or those features have the potential to be improved before they are finalized. Otherwise, what's the point?
BTW, I googled several different phrases trying to find a horror story in Node.js because of their experimental features, but the only thing I was able to find was people glowing about the features that are currently experimental and/or the excitement when a feature graduated to fully supported, for example:
https://nodesource.com/blog/experimental-features-in-node.js/
Maybe you can find examples of downsides of having experimental features in Node.js (or some other language/platform) that I was unable to find? If so, it would be instructive to learn from their experiences.
Using the trivial json_validate() example (although as others have said, a
simple new function is probably a bad example),
(As an aside, I disagree that a new function would be a bad example. I think it would be a good use-case for experimental features because of how decoupled it would be from the rest of the language, and it would help to see if a lot of people use the function before committing to including it.)
If it's the former, the library can just check if PHP >= 8.3 and fall back
to userland implementation / polyfill for earlier versions. This is just
what we have now, where approved new features are part of a versioned
release.
Not all potentially useful functions can reasonably be implemented in userland PHP.
If it's the latter, everyone touching the experimental version, directly or
indirectly, may have to rip out and change code later which renders the
work they've put in to use the experimental feature in their code pointless.
That is not a hard software engineering problem. Software developers have been isolating 3rd party dependencies for decades. There's no reason why developer could not isolate (most) potential experimental features in the same way.
I'm inclined to suggest if you opt in to an experimental language feature,
you are by definition making at least an implicit declaration that you know
what you're doing,
You speak of people "knowing what they are doing" as if it were a binary thing, i.e. they know what they are doing or they do not. Let me use an analogy for you here to try to make the counter point.
There are a handful of doctors of the world's leading heart surgeons. They absolutely "know what they are doing." But if I have brain cancer and need a tumor excised, I would not let any one of those doctors touch me unless they were also celebrated as a brain surgeon. I am guessing you would feel the same.
Similarly, someone can be an excellent software developer but not have strong DevOps or sysadmin skills. In my 10+ years working with PHP I met, knew, and worked with many people like that. And for many years, I was one of those people.
so the idea people using these features wouldn't have
the skills to spin up a container or install something on a VM doesn't
convince me, personally.
Not every developer is a polymath. Some are excellent at writing software but cannot configure a server or a VM or Docker container to save their life. In my LinkedIn I could probably give you a list of 100 developers what that would apply to.
IOW, they are a lot of excellent heart surgeons out there but they just don't know how to fix a brain.
-Mike
Am 11.10.2022 um 07:09 schrieb MKS Archive mike@newclarity.net:
This is what's bothering me. Either these "experimental" features have
passed RFC and will be part of the language, as you've said above, or
they're actually experimental i.e. not finalized and implementing behaviour
and syntax which may be subject to change or even dropped entirely
depending on the feedback cycle.If they are not experimental and their usage is finalized, then they are in-fact approved and they would be absolutely no different from the existing RFCs today.
You cannot have experimental features unless those features have the potential to not be included in the future language and/or those features have the potential to be improved before they are finalized. Otherwise, what's the point?
We seem to have two different views on experimental feature here: You are saying they could get removed again while others stated it is for stuff which will definitely end up in stable when the next major release is done.
IMHO there needs to be a consensus about this before we can continue the discussion, otherwise we will go around in circles.
Using the trivial json_validate() example (although as others have said, a
simple new function is probably a bad example),(As an aside, I disagree that a new function would be a bad example. I think it would be a good use-case for experimental features because of how decoupled it would be from the rest of the language, and it would help to see if a lot of people use the function before committing to including it.)
That's another thing where we need to find an agreement first: Are we talking new, isolated functions or are we possibly also talking about core new language features (i.e. new syntax / semantics)?
The work for maintenance by core developers could be much higher if it is not limited to new functions.
This is IMHO an important aspect as we do not want to make life even harder for the core team.
Hot take: If it is only about new functions then we don't need anything in the core, just create an \Experimental package with poyfills and you're done ;-)
If it's the former, the library can just check if PHP >= 8.3 and fall back
to userland implementation / polyfill for earlier versions. This is just
what we have now, where approved new features are part of a versioned
release.Not all potentially useful functions can reasonably be implemented in userland PHP.
... but almost all of them can.
I'd go as far as saying that while emulating json_validate() using json_decode() is slower and uses more memory it still is a valid polyfill. It is IMHO easy enough to develop with a higher memory limit and performance is not that critical for development either.
And unless you want to ship experimental code to production (which you shouldn't) you will have to wait for the next major PHP release anyway.
- Chris
We seem to have two different views on experimental feature here: You are saying they could get removed again while others stated it is for stuff which will definitely end up in stable when the next major release is done.
An experimental feature definitely might (although highly unlikely) get removed again - that's part of the idea that a feature can change, evolve or downright be cancelled.
But I think the point was to say that experimental features still have to undergo a full RFC process (possibly with a lower voting threshold) and are generally expected to be stabilized somewhere in the next few major/minor releases. The stabilization may take a while - there are some components of Kotlin which are still experimental since the 1.0 release (2016), but most of the features are stabilized in a span of two releases.
Overall the idea of experimental features is allow PHP maintainers to make mistakes, thus lowering the requirements for feature's refinement and try it on real users in real world projects instead of attempting to think every possible little detail through when creating an RFC, most of the time having zero analytics/statistics. Decisions needs to be made based on data if possible instead of premature conclusions, and experimental features aim to allow just that.
That's another thing where we need to find an agreement first: Are we talking new, isolated functions or are we possibly also talking about core new language features (i.e. new syntax / semantics)?
The work for maintenance by core developers could be much higher if it is not limited to new functions.
This is IMHO an important aspect as we do not want to make life even harder for the core team.Hot take: If it is only about new functions then we don't need anything in the core, just create an \Experimental package with poyfills and you're done ;-)
Both. Experimental features certainly do apply to new syntax & semantics too. It would have definitely been very useful for past RFCs - short closures, sealed classes, useland operators, pipe operator etc.
Regarding the polyfills, how is this gonna work? Say a new feature gets introduced and then it's arguments order changes, what a polyfill is gonna do here?
... but almost all of them can.
I'd go as far as saying that while emulating json_validate() using
json_decode()is slower and uses more memory it still is a valid polyfill. It is IMHO easy enough to develop with a higher memory limit and performance is not that critical for development either.And unless you want to ship experimental code to production (which you shouldn't) you will have to wait for the next major PHP release anyway.
Generally, the "experimental" part of the feature only applies to the syntax/semantics/spec, not to the actual implementation. This means that there's no reason to avoid shipping experimental code to production - you might need to change it in the future, but it doesn't mean it's just going to suddenly break out of nowhere. Runtime stability is expected to be on par with the stability of "regular" features.
We seem to have two different views on experimental feature here: You are saying they could get removed again while others stated it is for stuff which will definitely end up in stable when the next major release is done.
IMHO there needs to be a consensus about this before we can continue the discussion, otherwise we will go around in circles.
True. In my view experimental would allow to features to be tried that might get removed, but others may not want that.
However, I think it is really a moot point because of RFC voting. If enough people felt it might get removed they would vote against it. And if after something was experimental if enough people felt it should be removed they would vote to do so.
So each individual RFC as well as voting addresses that concern.
That's another thing where we need to find an agreement first: Are we talking new, isolated functions or are we possibly also talking about core new language features (i.e. new syntax / semantics)?
The work for maintenance by core developers could be much higher if it is not limited to new functions.
This is IMHO an important aspect as we do not want to make life even harder for the core team.
Again, each individual RFC and voting address that concern.
If an experimental RFC would resolve it "too much" maintenance by core developers then it would get voted down. A 2/3rd bar for success is not a low bar, especially in a community with so many divergent opinions.
Hot take: If it is only about new functions then we don't need anything in the core, just create an \Experimental package with poyfills and you're done ;-)
My hot take: Having the entire PHP community made aware of a given experimental function — including all the blog posts that would be written about it — is != to an individual developer creating an \Experimental namespace and writing their own blog post about it.
Not all potentially useful functions can reasonably be implemented in userland PHP.
... but almost all of them can.
See reply in prior paragraph.
I'd go as far as saying that while emulating json_validate() using
json_decode()is slower and uses more memory it still is a valid polyfill. It is IMHO easy enough to develop with a higher memory limit and performance is not that critical for development either.
For json_validate() people have already been using a polyfill, and it was found sorely lacking for memory-use reasons. So a reason for making it experimental would be to see if the proposed signature was sufficient for mainstream needs.
Oh, and a higher memory limit is not always a viable solution.
And unless you want to ship experimental code to production (which you shouldn't) you will have to wait for the next major PHP release anyway.
Not all "production" code is equal. My blog != Wikipedia, for example.
-Mike
I am back into PHP internals.
After reading again and again, I would like to say that I think we
should keep the release process as it is. If there is a feature not
currently available in the current release, .... at least a user has
the possibility to download and compile the code by itself; not the
best practice but ... for sure ... consistent and possible.
I think we should keep the release process as it is, until a real
scenario shows up, that would make us think about experimental
features.
My two cents...
Why can't "common users" install a PECL extension? It's not a difficult,
obscure or undocumented process.
A lot of developers (most?) who build PHP applications run them in shared-hosted or managed hosted servers where are never given the option to install a PECL extension.
In the rare cases they can install PECL many of those PHP developers would not have the skills to do it or the requisite permissions on the server; I certainly did not for the first ~10 years of working with PHP. I do now, but ironically because I have mostly moved away from programming in PHP to do more DevOps work.
Further, when working in multiple environments having to set up each server to have all the same PECL installations can be just too much hurdle so that developers won't even try, especially when working in managed environments.
[1] https://stackoverflow.com/a/12750694/102699
I can accept the reasoning
Apply a PECL strategy to try experimental features might not be the
convenient way always, for example, if we create a new ... sensitive ini
setting that affects the behavior of PHP somehow... OR ... what about a new
sensitive funtion in a "core extension" like JSON?But why would the answer in those cases not be "compile the PHP fork/branch
with the experimental feature", rather than find a way to flag the engine
to switch arbitrary new features on or off, complete with all the
complications in the primary source code that would cause? We are, after
all, talking about features which by definition should not be relied upon
for any production use.Or we're talking about features which are stable and valuable enough to
have passed an RFC process, but then what's gained from an experimental
designation? Why couldn't they just be included in a preview/beta/RC
version which anyone could decide to run or not?
It does not seem reasonable that the bar to include a feature as experimental should be the same bar as currently exists for forever features. Opinions expressed on the list typically fall into one of three categories:
1.) Please, please yes!
2.) No way whatsoever! or
3.) I am not convinced...
Generally it seems that unless 2/3rd are in the #1 category an RFC fails to pass, even if after evaluating in the wild the people in group #3 might come to see a lot of value in it and some in #2 might even change their mind. In those cases PHP suffers.
If there were an RFC for Experimental Use then the people on the fence could choose to allow it to see how it plays out in real-world userland cases, and a few people against it might be convinced to allow people to evaluate it, and then later make a decision on a "Forever RFC."
Also, the comments along the lines of "Well, this could quickly get out of hand" presume that the people voting for experimental use won't take that into consideration and vote against things if it seems like things are in-fact getting out of hand. But they will take that into consideration just a as the take other concerns into consideration now, and thus only the better ideas will be likely to make it through to experimental status.
One more thing on this topic. PHP could ALSO allow experimental features to be written in PHP, and ship those experimental features with PHP so that code would always be available, at least when experimental features are turned on, and without having to include said code.
The benefit there would be people could more quickly implement an experimental feature to see how it might work in the wild before going to all the effort to implement in C in PHP's core code, for things that can be implemented in PHP.
-Mike