I'm not convinced it does, actually. Consider the following trait:
trait PropertyCount {
public function count(): int {
return count(get_object_vars($this));
}
}
This trait CAN be used to implement the built-in Countable interface, and it might be useful to label it as such; but does it really make sense to say
that classes MUST implement that interface?
IMO yes, it does. This simplifies rules for detecting implementation of interfaces in
traits, so you don't get "yes and no" answers in that case.
I'm not really sure why would you not want this - what is the point of marking method as interface implementation, if it is not reflected by type
system in actual execution? If it does not make sense in case of your `PropertyCount`, then do not use this feature.
Even if we put it as a requirement, we can't guarantee that the class will actually use the trait's implementation of the interface, because this
would still be valid:
class Foo implements Countable {
private $whatever;
use PropertyCount {
count as getPropertyCount;
}
public function count(): int {
return 0;
}
}
It works the same for classes and inheritance - if you declare `Foo::count()` directly in class, I can always create `FooBar extends Foo` that
overwrites your implementation. But I never heard that someone complain about it, so I'm not sure why this is suddenly a problem for traits. Ensuring
that particular implementation is used is not the purpose of interfaces, it never was.
Also note that right now method signatures from trait can be changed by class,
so PHP won't complain about this:
trait T {
public function t(string $t): void {
}
}
class C {
use T {
t as tt;
}
public function t(): string {
return 't';
}
}
This proposal gives you tools to ensure that class does not mess up with method signatures expected by trait - you can create pairs of trait-interface
and require interface in trait.
--
Regards,
Robert Korulczyk
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
