Re: [RFC] [Discussion] Add ReflectionAttribute::getCurrent()

On Sun, May 17, 2026 at 7:06 AM Valentin Udaltsov < udaltsov.valentin@gmail.com> wrote: > Daniel Scherzer <daniel.e.scherzer@gmail.com>: > >> 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