Re: Re: [RFC] [Discussion] #[\DelayedTargetValidation] attribute
On Sun, Jul 6, 2025 at 5:48 AM Tim Düsterhus <tim@bastelstu.be> wrote:
> Hi
>
> On 7/5/25 00:49, Daniel Scherzer wrote:
> > If there is no further feedback, I intend to start a vote in a few days..
>
> Looking at your #[\Deprecated] for traits RFC
> (https://externals.io/message/127912):
>
> How will #[\DelayedTargetValidation] interact with the validator of
> zend_internal_attribute? Would applying #[\DelayedTargetValidation] +
> #[\Deprecated] on a regular class error or not?
>
> Best regards
> Tim Düsterhus
>
For validators, an extra flag is passed to the validator to indicate if
target validation should be disabled, in which case the errors about
targeting the wrong type of thing (e.g. a non-trait in the case of
#[\Deprecated]) are suppressed until runtime as well. Thanks for pointing
this out - I actually hadn't done this properly, fixed it now - take a look
at the "errors_from_validator.phpt" and "validator_success.phpt" test cases
in the PR.
The reasoning here is exactly the same - validators are used to verify that
an attribute is being used on things that are appropriate, just like
targets. While the only current (non-zend_test) validator is for dynamic
properties, and it is less likely that there will be a future where the
validator accepts more things, we shouldn't assume that things will never
change, e.g. I wouldn't object to allowing #[\AllowDynamicProperties] for
read-only classes. But this will also set the stage for the #[\Deprecated]
validator - that validator will enforce that a zend_class_entry is for a
trait, but if validation is delayed then it will allow using #[\Deprecated]
on interfaces or classes and the error being delaying until runtime.
-Daniel
Thread (19 messages)