2024년 3월 29일 (금) 오후 5:43, Stéphane Hulard <s.hul...@chstudio.fr>님이 작성:
> Le vendredi 29 mars 2024 à 03:39, 하늘아부지 <daddyof...@gmail.com> a écrit : > > > 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. > > > > > Best Regards. > > Daddyofsky > > Hello ! > > I took a look at your proposal and I think about important issues if we go > this way. > > A static method mustn't used the `$this` variable because it simply > doesn't exists in the static context. The examples you're adding in the RFC > are fine but they always rely to a specific `__callStatic` implementation > that will use a new instance of the object to forward the call. > > There are multiple cases where it'll be complicated to use it this way. > Two of them I have in mind: > > - What if the object needs important parameters in its constructor that > aren't available in the static context ? Or those parameters need to be > initialized outside of the `__callStatic` method? > - What if the underlying non static method we are trying to invoke is > using the `$this` variable? > > In those two examples, I would prefer having a fatal error that explains > that I'm not doing the call correctly (calling a non static method in the > static context) to ensure it'll be easy to understand and fix. > > The use cases you are describing here have been fixed in the user space by > the Laravel team. It's a very specific way of working that's mostly > specific to Laravel. > > For sure it makes the code harder to read since you can't jump to a real > method easily (because most of the methods are magic ones and are forwarded > to underlying objects). I don't tell it's wrong but I'm not sure it's > relevant to make the whole language simplify this process. > > If there is a way to work correctly with those static vs non static calls > and capture relevant errors to expose them to users, that's fine. > > However, I think this is an important behavior change because it'll allow > a new way to work with method that were forbidden before. > > Regards > Stéphane Hello. Thank you for your interest. In fact, `__callStatic` is often used for static-like singletons, and such examples are likely to be the majority. Regarding the two issues you pointed out, the first can be resolved by adding an initialization method like `init`. It's common to use a separate initialization function when dealing with general class operations, especially when there is a lot to initialize. The second issue is actually the same problem that exists today. Since `__callStatic` is called in the case of static calls to private or protected methods, the use of `$this` is not exclusive to public methods. In other words, the `$this` issue applies the same way it does now. Allowing public methods does not create a problem that didn't exist before. If it had been the case that calling non-static methods statically always resulted in an error, the issues you raised would have been significant. However, private and protected methods can already be called without error. Even if this RFC is not accepted, the points you mentioned still apply. Regards Daddyofsky
