Re: [RFC] Attributes v2

> On Mar 11, 2020, at 5:36 PM, Rowan Tommins <rowan.collins@gmail.com> wrote: > > On 11/03/2020 19:12, Mike Schinkel wrote: >> My gut feeling is that attributes should be specific to the classes in which they are >> declared. But I see no reason a "must-add" requirement for attributes where the >> requirement is passed down to a concrete class needs to be coupled to a inheritance of attributes. > > From an "interfaces are contracts" view, I totally agree. I'm just thinking in > terms of implementation: the requirements we currently enforce are implemented as > abstract+inheritance, so that seems like the most straight-forward thing to copy. If attributes > aren't inherited, but "attribute requirements" are, we'd need them to be a > different kind of thing in some way. > > I also think that applying attributes to an interface directly might have uses, so we'd > need separate syntax for the two things. Definitely agree. > For instance, looking at the Hack manual, the built-in __Sealed attribute has specific meaning > for interfaces: > > > An interface that is sealed can be implemented directly only by the classes named in the > > attribute value list. > > > https://docs.hhvm.com/hack/attributes/predefined-attributes#__sealed > >> It could certainly be implemented in userland by the code that consumes the interface. But >> not every consumer will implement it > > The way I was thinking of it, and I think the way this RFC is drafted, the native attributes > would - at least initially - be a very low-level feature, with libraries expected to build more > useful functionality on top. So if a library gave meaning to << Require(SomeAttribute::class) > >> then all consumers of that library would give that the same meaning. I read that last sentence 10 times but still am not sure what it means. Can you maybe give a concrete example? > further there would be no syntax for a static analysis tool or IDE to use to recognize the > requirement. > > Very true. Although given the amount of parsing some tools already do with docblocks, if there > was a popular library defining attributes like this, the tools would probably start picking up on > it. How would they pick it up if there is no way for an interface to say "You must include this attribute?" Adding an attribute to a class would not be the same as assigning a literal value to an untyped variable. In the latter case the IDE can reasonably assume the variable should be that type even if it gets it wrong in a few cases. In those few cases the developer just ignores the little squiggly underline saying its the wrong type. Or the developer can explicitly type it with PhpDoc so the IDE will get it right. But when a class implements an interface and also uses an attribute the idea that is not necessarily a signal that all other classes that implement that interface should also use the attribute. Especially if a class implements multiple interfaces; which one should implement it? And if the interface is from an external source and there is not yet any uses, how could the IDE know when an attribute is required? >> Hence why I'd love to see that ability to specify in an interface when a class must >> implement attributes. >> [...] >> P.S. And while I am at it, I would also really like to be able to require static methods >> and constants via an interface, too. > > > Oh, I'd love to see all of those things, but as DanAck says, they deserve a separate > discussion to figure out what it would all look like, and in the meantime getting an actual native > attribute syntax to build them on top of would be a huge step forward. I'd happily agree with this, assuming we make sure the syntax choice does not paint us into a corner we cannot get out of in a future discussion. -Mike