On Sun, Jul 6, 2025 at 5:48 AM Tim Düsterhus <t...@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
