On Thu, May 2, 2024 at 1:00 PM Benjamin Außenhofer <kontakt@beberlei.de> wrote:
On Tue, Apr 23, 2024 at 3:27 PM Benjamin Außenhofer <kontakt@beberlei.de> wrote:
Hi internals,
My PR for #[\Deprecated] attribute was in hibernation for a long while now and after some off-list discussion a few weeks ago I have decided to revisit it and asked Tim to help me out with the work.
Tim has cleaned up the PR quite a bit and also worked in additional features such as #[Deprecated] support in stub generation.
While there are still some small todos, at this point we want to restart the discussion about the RFC for inclusion in 8.4:
We have updated the RFC and PR to include #[Deprecated] on class constants and enum cases as this is something the engine already supports for internal class constants.
This does not include support for non-class based constants, because they don’t have support for attributes at the moment and also only recently got reflection support (for 8.4).
We are planning to work on adding $since next and get back to the list once that is finished.
The $since implementation is now added to the RFC and to the PR.
We decided to make this a secondary voting choice, while there are use-cases for it in php core for doc rendering, other ways of doing the same thing are also available and given userland frameworks stated different requirements maybe its better left for userland to implement.
On Tue, Apr 23, 2024 at 3:27 PM Benjamin Außenhofer <kontakt@beberlei.de> wrote:
Hi internals,
My PR for #[\Deprecated] attribute was in hibernation for a long while now and after some off-list discussion a few weeks ago I have decided to revisit it and asked Tim to help me out with the work.
Tim has cleaned up the PR quite a bit and also worked in additional features such as #[Deprecated] support in stub generation.
While there are still some small todos, at this point we want to restart the discussion about the RFC for inclusion in 8.4:
Feedback period is now nearing 4 weeks and the last 2 have not brought any new significant discussions, as such we plan to open the vote next Wednesday if no new roadblocks come up.
On Fri, May 17, 2024, at 9:53 AM, Benjamin Außenhofer wrote:
On Tue, Apr 23, 2024 at 3:27 PM Benjamin Außenhofer <kontakt@beberlei.de> wrote:
Hi internals,
My PR for #[\Deprecated] attribute was in hibernation for a long while now and after some off-list discussion a few weeks ago I have decided to revisit it and asked Tim to help me out with the work.
Tim has cleaned up the PR quite a bit and also worked in additional features such as #[Deprecated] support in stub generation.
While there are still some small todos, at this point we want to restart the discussion about the RFC for inclusion in 8.4:
Feedback period is now nearing 4 weeks and the last 2 have not brought
any new significant discussions, as such we plan to open the vote next
Wednesday if no new roadblocks come up.
Thank you to all participants for the feedback.
greetings
Benjamin
Why is the attribute not allowed on classes? I think it would make sense on every language structure, unrestricted. (Including classes, parameters, everything.)
The user-space definition of the attribute is invalid in the example: It declares properties AND promoted constructor args. That can/should be combined.
Why is the attribute not allowed on classes? I think it would make sense on every language structure, unrestricted. (Including classes, parameters, everything.)
There is not pre-existing semantics of deprecating a class from the engine PoV.
The only things that can be deprecated on the engine level as of now are Functions, Methods, Class Constants (incl. Enum Cases), and regular Constants (those do not support attributes).
Allowing to apply the attribute on classes is therefore left to future scope (as mentioned in the “Future Scope” section of the RFC). Adjusting the attribute to also apply to classes once the semantics are decided should be straight-forward and thus be an implicit part of the process of supporting the deprecation of classes.
The user-space definition of the attribute is invalid in the example: It declares properties AND promoted constructor args. That can/should be combined.
I don’t follow. Do you mean the top-most codeblock in the RFC? It does not use constructor property promotion.
It’s the stub, intentionally omitting the method body. I’ve added a placeholder comment in the constructor body to make that clearer.
On Fri, May 17, 2024, at 3:49 PM, Tim Düsterhus wrote:
Hi
On 5/17/24 17:02, Larry Garfield wrote:
Why is the attribute not allowed on classes? I think it would make sense on every language structure, unrestricted. (Including classes, parameters, everything.)
There is not pre-existing semantics of deprecating a class from the
engine PoV.
The only things that can be deprecated on the engine level as of now are
Functions, Methods, Class Constants (incl. Enum Cases), and regular
Constants (those do not support attributes).
Allowing to apply the attribute on classes is therefore left to future
scope (as mentioned in the “Future Scope” section of the RFC). Adjusting
the attribute to also apply to classes once the semantics are decided
should be straight-forward and thus be an implicit part of the process
of supporting the deprecation of classes.
This would be helpful to include explicitly in the RFC, toward the top, because it's the first thing that came to mind when I saw the initial code block.
The user-space definition of the attribute is invalid in the example: It declares properties AND promoted constructor args. That can/should be combined.
I don’t follow. Do you mean the top-most codeblock in the RFC? It does
not use constructor property promotion.
It’s the stub, intentionally omitting the method body. I’ve added a
placeholder comment in the constructor body to make that clearer.
Ah, I misread it. You are correct, it's valid. It's so rare I see a name in both the constructor and as a property these days.
