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
signature.asc
Description: OpenPGP digital signature
