2024년 3월 29일 (금) 오후 10:21, Larry Garfield <la...@garfieldtech.com>님이 작성:
> On Fri, Mar 29, 2024, at 2:39 AM, 하늘아부지 wrote: > > Hello. > > > > I created a wiki for __callStatic related issues. > > Please see: > > https://wiki.php.net/rfc/complete_callstatc_magic > > I look forward to your interest and advice. > > I am firmly against this proposal. > > I think my objection boils down to this line in the RFC: > > > Of course, calling non-static methods in a static-like manner can be > confusing, but in modern PHP, it has already become common practice. > > I would argue this statement is false. Calling non-static methods in a > static-like manner is confusing, which is why in modern PHP one should > never do that, and respect that static and non-static methods exist in a > separate universe. Static methods are methods *on a type*. Non-static > methods are methods *on an instance*. Those are not the same thing.[1] > > It would be more accurate to say "calling non-static methods in a > static-like manner is common *in Laravel*," where the badly-named "facades" > system serves as a poorly designed, hard to debug, hard to test, archaic > alternative to using dependency injection. While there may have once been > an argument that DI was "too hard" for simple cases a decade ago or more > (though even then I think it was a bade trade-off), the combination of > auto-wiring DI Containers (which Laravel pioneered in PHP) and constructor > promotion (introduced in PHP 8.0, 3.5 years ago.) completely eliminates > those arguments. The level of effort to do actual DI today is trivially > small, and the benefits over magic hidden globals are massive. > > Laravel Facades are a relic of an older time best avoided, even in Laravel > projects. (I am far from the only person to argue this; many even within > Laravel's inner community make this argument.) > > Adding features to the language that seemingly exist only to make that > particular buggy hack easier to do is a step backwards, and I would argue > harmful for the language. On the contrary, I would favor going the other > direction: Calling a static method as though it were non-static currently > works, and I would support making that an error, to further emphasize that > static and non-static methods are not interchangeable. > > [1] https://peakd.com/hive-168588/@crell/cutting-through-the-static > > --Larry Garfield > Thank you for your feedback. I agree that static and non-static should be distinct, which is a given. There are a few points I'd like to make. First, my proposed RFC is not about allowing non-static methods to be used statically. Although all my examples use `::`, they internally operate on an instance. Inside `__callStatic`, an instance is created and used for operations. Second, as already possible through the `__callStatic` method, non-static methods can be called as if they were static (as mentioned, this does not mean they operate statically). For protected and private methods, the `__callStatic` function is invoked even for non-static methods. This might not be to everyone's liking, and to others, it might be a favorite feature. It might operate differently from the initial intention when `__callStatic` was introduced. However, I don't think this is necessarily a bad thing. Isn't it developers who bring to life ingenious ideas that were unforeseen? Third, as you can see from my examples, what I propose could be a solution to the current issues. Since it does not work for public methods while it does for protected and private ones, it has led to code becoming more obscure and layered through facade-like patterns. It's like taking a longer route because the road is blocked, or creating a dog door because the main door is closed. >From the perspective of those who develop the PHP language itself, my proposal might not be appealing. However, I believe from the user's standpoint, my proposal could lead to more convenient and cleaner coding practices. Didn't PHP start as a language meant to be user-friendly? Regards Daddyofsky
