On 17/01/2022 18:03, Mike Schinkel wrote:
"...I must implement an abstract method"
"...I must implement all the methods in an interface"
"...I must pass all arguments declared in a function"
"...I must pass arguments that are of the type that were type-hinted"
In all of these cases, failing to meet the requirements means the code
*probably won't work correctly*.
As I've said previously, there are legitimate cases where a trait *uses
the methods from an interface*, which is a similar scenario. That use
case is currently covered by including abstract methods in the trait,
and while "requires interface" could be a short-hand for that, it's been
made clear to me that that is not the use case people are talking about.
"...I cannot extend a final class"
"...I cannot access a private property outside the class"
"...I cannot change a readonly property after it has been initialized"
These are more relevant comparisons, because there could be valid uses
of the class which violate the restrictions; and particularly "final" is
often used out of principle rather than specific need. However, they do
allow the author of the class to make certain assumptions about how it
will behave - for example, if a property is private, you know exactly
which lines need changing if you want to rename it; if a class is final,
other code referencing it can make stronger assumptions than its method
signatures; and so on.
The difference with the "trait requires interface" proposal is that I
don't understand what advantage it gives the author of the trait. What
decisions can you make as a library developer because you've said "users
of this trait must implement the matching interface" as opposed to "...
can implement the matching interface"?
It's possible there is some advantage I'm missing, but so far nobody
seems to have presented it.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
