On Fri, Mar 29, 2024, at 3:33 PM, 하늘아부지 wrote: > 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?
Developers also bring to life horrible monstrosities that are an afront to all that is holy. I am a developer. It's what we do. :-) Especially when VC money is involved. Not all "innovation" is good. > 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. It simplifies a practice that should not be a practice in the first place. That's not a net-win. > 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? I don't actually work on the PHP engine, I just write RFC text for other people; I have ~25 years of experience writing user-space PHP. And no, anything involving stealth globals via statics is the opposite of "more convenient and cleaner." --Larry Garfield
