Re: [RFC] Invoke __callStatic when non-static public methods are called statically

On Fri, Mar 29, 2024, at 3:33 PM, 하늘아부지 wrote: > 2024년 3월 29일 (금) 오후 10:21, Larry Garfield <larry@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