On Thu, May 8, 2025 at 8:38 AM Tim Düsterhus <t...@bastelstu.be> 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
