Hi Daniel On Thu, May 8, 2025 at 5:48 PM Daniel Scherzer <daniel.e.scher...@gmail.com> wrote: > > So this example would emit deprecation warnings on all getting and setting > operations, but I was thinking that they would *not* be emitted when being > accessed from within the same class (private scope). Consider a project that > * does not want to use hooks (which add overhead) > * wants to support the deprecated behavior > > It would then want to > * emit warnings when a property is accessed by protected/public scope > * but need to handle any writes from outside of the class by accessing the > property internally to see if the value changed > > I'm not sure what NAK means in this context, but I think that allowing > `#[\Deprecated]` directly on the property instead of needing to use hooks be > done in the same way that the property hooks were implemented in terms of > dealing with VM handling and opcache, where things are not cached (I assume, > haven't looked into this enough, this is just a preliminary discussion). > > Allowing deprecation directly on properties would also be more performant > than needing to use hooks.
I would echo what Niels said. Deprecations for internal functions were added before my time, and it made sense to expand this functionality to userspace, as the two should generally be congruent. I am not in favor of adding more runtime deprecations to hot code. Runtime deprecations are not a great solution in the first place, deprecations are much easier to catch through static analysis. Function deprecations made sense for us because we needed them internally, but I don't think we have a use-case for the properties. If they were trivial and free to add to runtime, I wouldn't mind as much. But they are neither of those things, in addition to being a bad solution to the original problem (reminding you to fix your code). Hence, I would prefer not adding more checks. Ilija
