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.
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.
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.
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.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
