2024년 3월 30일 (토) 오전 1:21, Larry Garfield <la...@garfieldtech.com>님이 작성:
> 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 > Hi. > It would be more accurate to say "calling non-static methods in a static-like manner is common *in Laravel* It might be correct to say that this is specific to Laravel. The problem, however, is that Laravel is used so extensively that it cannot be ignored. There's a point of embarrassing me. It's as if my proposal, if accepted, would create problems that did not previously exist. Yet, the existence of `__callStatic` already allows for the issues you've pointed out to occur. You can already write code like `foo::bar()::baz()` with the current PHP. The possibility of more problems arising could indeed be true. In that sense, I understand your point. And unless `__callStatic` is intentionally used, calling non-static methods statically will still result in an error, just as it does now. I am simply proposing to give users the choice when they intentionally use `__callStatic`. Daddyofsky
