Re: Initial discussion - more deprecation options
On Thu, May 8, 2025 at 8:38 AM Tim Düsterhus <[email protected]> wrote:
> Hi
>
> Am 2025-05-07 21:43, schrieb Niels Dossche:
> > Definitely NAK on deprecating properties, which has the potential of
> > adding lots of overhead.
>
> FWIW: Deprecating properties is already possibly by means of deprecating
> a property hook. I guess this is an acceptable workaround to not require
> a dedicated support + associated complexity.
>
> see: https://3v4l.org/C6jRQ
>
> class Foo
> {
> public string $foo
> {
> #[\Deprecated]
> get {
> return $this->foo;
> }
>
> #[\Deprecated]
> set {
> $this->foo = $value;
> }
> }
> }
>
> $f = new Foo();
> $f->foo = 'dummy';
> var_dump($f->foo);
>
>
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.
-Daniel
Thread (7 messages)