Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127325
Precedence: bulk
MIME-Version: 1.0
References: <CALaXqqT1s3Qyhi0FEfybbycjefwUSuojENaU1owfUV_nMHxAog@mail.gmail.com>
 <5eebf119-aeff-4d1e-8f84-0e91f7c89bb4@gmail.com> <c3232274267ef2ca4d1833408e73c8c7@bastelstu.be>
 <CALaXqqT8aaJNQwxqgh4XUAVKYqrCz1iWmL6iLocWvSBDbsLVCA@mail.gmail.com>
In-Reply-To: <CALaXqqT8aaJNQwxqgh4XUAVKYqrCz1iWmL6iLocWvSBDbsLVCA@mail.gmail.com>
Date: Thu, 8 May 2025 23:22:53 +0200
Message-ID: <CAPyj-LCsFnC36UH7egrzoNX5W-vZ72s9w3g5o6e7g_oYDJfOiw@mail.gmail.com>
Subject: Re: [PHP-DEV] Initial discussion - more deprecation options
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Daniel

On Thu, May 8, 2025 at 5:48=E2=80=AFPM Daniel Scherzer
<daniel.e.scherzer@gmail.com> wrote:
>
> So this example would emit deprecation warnings on all getting and settin=
g operations, but I was thinking that they would *not* be emitted when bein=
g accessed from within the same class (private scope). Consider a project t=
hat
> * 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 th=
e 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 d=
ealing 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