On Tue, Apr 28, 2020, at 10:56 AM, Nicolas Grekas wrote: > > > > > I would expect attributes to apply only to the properties on my side. > > > > Parameter annotations could be interesting for dependency injection. > > Symfony currently has some DI magic through parameter names among > > other things. It might be nice to control these through annotations > > instead. This would be impossible or involve a lot of hackery and > > assumptions if the annotations aren't available on the parameters. > > Alternatively we might make this information available through > > reflection (like ReflectionParameter::getGeneratedProperty()) so you > > can look for the annotation there. > > > > Sure, this could be considered. > > But this doesn't contradict what I wrote: > if one uses constructor promotion, the then attributes should only go to > the properties to me. > If one wants to add attributes to parameters, then one would need to > opt-out from constructor promotion. > > Nicolas
I'm inclined to agree with Nicolas. My gut feeling (and I don't have more data to back it up than that, I admit) is that property annotations will be more prevalent than parameter annotations, so those should take precedence. That said... how many will conflict? In practice, the most common use case I can see for parameter attributes would be fancy DI configuration for services... and I don't know that I'd care about attributes on the properties in that case. Conversely, for properties that have attributes that will usually be for extended type information, ORM mapping, and stuff like that. For which... I can't think of what I'd want attributes I'd want on the parameter itself. Perhaps I'm just not creative enough at this hour, but I'm not sure that "both" is such a problem. It only seems like it would be an issue for attributes that user-space wanted to enforce on certain cases only; since attributes are new, a viable answer there is "btw, if you're restricting your annotation be aware of this double-case and either allow it or don't, but it's on you to decide what if anything to do." --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
