On Mon, Jun 19, 2023 at 9:53 PM Rowan Tommins <rowan.coll...@gmail.com>
wrote:
> On 19/06/2023 20:20, David Gebler wrote:
> > Okay, thanks. That's really quite significant, since it changes the
> feature
> > to one which could allow changes made to interfaces to adversely impact
> > existing clients of an interface without those clients changing a thing.
>
>
> As the RFC says, it introduces a form of multiple inheritance, and
> inheritance in PHP doesn't make any such guarantee - to adapt your example:
>
> class A {
> public function foo(): void {
> $this->bar();
> }
> }
>
> class B extends A {
> public function bar(): void {
> ...
> }
> }
>
> The job of detecting that class A doesn't define a contract for method
> bar falls to static analysers, and the same would be true for default
> implementations on interfaces.
>
>
>
>
Sure, but in this example were B::bar() to be a private method, you would
get a scope violation error. You would not if you were to use a trait,
since any methods implemented in the trait would be executed in the same
scope as the class using the trait. And that seems to be what's being
proposed here for interface defaults. So my concern here is that when you
use a trait, you know that what you're doing is effectively
copy-and-pasting implementation into your class scope. You don't expect
that when you declare a class to implement an interface.
There's some degree of irony to me that we have another RFC, the Override
attribute, which will introduce an engine-level check that could easily
(and arguably should) be left to static analysis tools, yet we're talking
here about introducing a mechanism where private methods on a class could
be called by stealth by a mere interface. I'm not even sure static analysis
tools would in their typical configuration pick up on a situation like
this, either, since it could in this scenario sit in a vendor dependency
and not your own code.
I like the idea of this RFC - in fact it's one which has been near top of
my wishlist for PHP language features for a long time - but I think this is
an issue with the proposed implementation which at the very least warrants
highlighting and discussion.
