On Sun, May 17, 2026 at 7:06 AM Valentin Udaltsov < [email protected]> wrote:
> Daniel Scherzer <[email protected]>: > >> Hi internals, >> >> I'd like to start the discussion for a new RFC about adding a new method, >> ReflectionAttribute::getCurrent(), to access the current reflection target >> of an attribute. >> >> * RFC: https://wiki.php.net/rfc/reflectionattribute-getcurrent >> * Implementation: https://github.com/php/php-src/pull/21440 >> >> Thanks, >> -Daniel >> > > Hi, Daniel! > > Thank you for your proposal. > > I think the problem you are trying to solve arises from mixing two > responsibilities in a single attribute class — it acts both as a data > container and as a place for resolution logic. Separating these concerns > makes the code cleaner and removes the need to access the > reflection target from within the attribute itself. > > In my opinion, an attribute should be a simple DTO, and the resolution > logic should belong elsewhere. Here's a small example of that: > https://gist.github.com/vudaltsov/6dbab6a69967a55037fc7d6b13bd593b Here > the messageClass can be inferred either from the attribute or from the > function signature — the Metadata class has a non-nullable messageClass, > and the attribute remains a plain DTO with an optional parameter. Of > course, you can add a MetadataDriver interface and move my static methods > to implementations, this will work especially well if you have multiple > configuration sources (YAML, XML, attributes, PHP DSL, etc.). > > So, I believe that attributes should not be aware of the context they are > declared in because the resolution responsibility does not belong to them. > > -- > Valentin > While separating the attribute data and the resolution is possible, in practice the resolution is frequently done in the attribute. This is already the case - my proposal just makes that resolution simpler. To be clear, code does not *need* to use the reflection access, and doing resolution outside of the attributes is (and will remain) perfectly acceptable. But given how much code already *does* do resolution within the attributes, this proposal would simplify that resolution code. See the AttributeUtils library for more context about how resolution is currently done in attributes. -Daniel
