On Tue, Jun 20, 2023 at 12:10 AM Levi Morrison <le...@php.net> wrote:
> > 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. > > I understand your concern but personally believe it's overblown. This > problem already exists with abstract classes, but doesn't seem to be > that much of an issue in practice. I hope static analysis can fill the > gap here, but don't think these checks are necessary to ship this > feature. > I agree that these checks would not be a requirement to ship this feature. I was thinking even further just as a thought experiment. Let's pretend for a second that these checks could easily be implemented, wouldn't it actually make it worse for the language as a whole? The only place where a method body would be forbidden to call `$this->foo()` ahead-of-time (compile-time or runtime with special error) would be on an interface default method. Everywhere else in the language would have the behavior of resolving the scope of `$this` and then attempting to actually execute the method. If the scope of `$this` has a `__call()` implementation, this would never lead to a "FatalError method not found" scenario, making these checks even weirder. What I'm concluding is that although it could have been nice to not allow these weird quirks, that ship has sailed decades ago and doing it on an interface default implementation (even if it was possible) would just create a major language inconsistency and it would always be best to implement this RFC without it regardless of technical limitations. -- Marco Deleu
