[PHP-DEV] Registration apply for php wiki
Hi, My name is JaeHan Seo. (wiki username is *daddyofsky*) I hope I can make a proposal by registering on the php wiki. Thanks.
[PHP-DEV] RFC Proposal : Allows calling non-static public methods through the __callStatic magic method instead of throwing an error.
Hi.
I'd like to propose an RFC, but I don't have the authority.
Below is my suggestion.
If you think this makes sense, please write an RFC for me.
Sincerely.
--
= Introduction =
Allows calling non-static public methods through the __callStatic magic
method instead of throwing an error.
= Proposal =
>From a conceptual perspective:
It goes without saying that calling a non-static method statically will
result in an error.
However, a confusing situation occurred when the __callStatic magic method
exists.
Non-public methods can be called, but public methods cannot.
This is the opposite of the method visibility policy.
>From a practical point of view:
If you can call Non-static public methods through the __callStatic magic
method, you can write code like Laravel ORM more simply and tidy.
User::foo()->bar();
Before
class Foo
{
protected static ?Foo $instance = null;
public static function __callStatic($method, $args)
{
$instance = self::$instance ?? self::$instance = new static();
return $instance->__call($method, $args);
}
public function __call($method, $args)
{
if (method_exists($this, $method)) {
return $instance->$method(...$args);
}
return $this;
}
protected function bar()
{
echo __METHOD__ . '';
return $this;
}
protected function baz()
{
echo __METHOD__ . '';
return $this;
}
}
Foo::bar()->baz();
(new Foo())->bar()->baz();
There is no error, but the concept of method visibility is broken.
All Non-public methods can be called at instance scope.
After
class Foo
{
protected static ?Foo $instance = null;
public static function __callStatic($method, $args)
{
$instance = self::$instance ?? self::$instance = new static();
if (method_exists($instance, $method)) {
return $instance->$method(...$args);
}
return $instance;
}
public function bar()
{
echo __METHOD__ . '';
return $this;
}
public function baz()
{
echo __METHOD__ . '';
return $this;
}
}
Foo::bar()->baz();
(new Foo())->bar()->baz();
This is more tidy.
Only public methods are callable at instance scope.
Re: [PHP-DEV] [RFC] Invoke __callStatic when non-static public methods are called statically
2024년 3월 30일 (토) 오전 2:15, Robert Landers 님이 작성:
> On Fri, Mar 29, 2024 at 3:41 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.
> >
> > Best Regards.
> > Daddyofsky
>
> Hey there,
>
> Some general feedback:
>
> The RFC is a bit hard for me to follow, for example:
>
> > However, the IDE cannot find active method, and the Go to Definition
> feature cannot be used.
>
> This sounds like a bug or feature request with your IDE, not a problem
> with PHP.
>
> > This code is very clear, aside from the fact that the method is not
> static.
>
> Clear to whom? As a developer this looks downright confusing. I can't
> even guess what the actual behavior is. If you call a non-static
> method statically, its currently an error. Why would this not be an
> error?
>
> > The IDE recognizes active methods well and the Go to definition feature
> also works properly.
>
> What is stopping the IDE to taking you to the __callStatic method?
> That would be the correct behavior IMHO, not the implementation for
> instance methods.
>
> > Even if there are only a few core methods, it cannot be made into a
> single file.
>
> There is nothing stopping you from putting multiple classes in a file.
>
> > As can be seen in the above examples, the code becomes clearer, and
> navigation through the IDE works much better.
>
> I completely disagree. It mixes concerns and makes spaghetti code into
> incomprehensible code. Also, maybe you should take up IDE navigation
> with your IDE?
>
> > Instead of throwing an error when a non-static public method is called
> statically, the _ _callStatic method should be invoked.
>
> I completely agree with this, btw. Your examples could use some work
> and shows all the reasons why it shouldn't call __callStatic(). A real
> life example, that has nothing to do with a specific framework:
>
> When generating proxies for existing types, you often need to share
> some state between the proxies. To do that, you put static
> methods/properties on the proxy class and hope to the PHP Gods that
> nobody will ever accidentally name something in their concrete class
> with the name you chose for things. To help with that, you create some
> kind of insane prefix. If __callStatic() were called ALWAYS in a
> static context, even if a non-static method exists, then collisions
> would literally be impossible. But at that point, why can't I just
> write:
>
> class Test {
> public static function test(): string { return "hello world"; }
> public function test(): int { return random_int(); }
> }
>
> ??? I feel like this is your real RFC and should be allowed if we're
> allowed to __callStatic() to instance methods. I don't think it makes
> sense to have one without the other, and then what you want with
> __callStatic() comes naturally, instead of this weird and confusing
> RFC.
>
>
> Robert Landers
> Software Engineer
> Utrecht NL
>
Hello.
I'm not very familiar with documentation. It would be helpful if you could
suggest how to fix the problematic parts.
Using the example of the IDE meant to illustrate that it should be
intuitive enough for the IDE to find it directly.
Even currently, `__callStatic` is called in cases of non-static methods
that are not public methods. `__callStatic` already acts as a rule-breaker.
It seems like there's a desire for the magic method to be named as such
without actually causing much magic. The current `__callStatic` is like a
magician who can use high-level magic to hit targets behind doors or
invisible targets but can't use basic magic to hit a visible door.
While it's good that the PHP kindly notifies errors, I think it would also
be beneficial to provide users with options to do other things,
specifically when they intentionally use `__callStatic`. That's the core
point of this proposal.
If there are better examples or ways to explain, I would appreciate
learning about them.
Daddyofsky
Re: [PHP-DEV] [RFC] Invoke __callStatic when non-static public methods are called statically
2024년 3월 29일 (금) 오후 10:21, Larry Garfield 님이 작성: > 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? 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. >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? Regards Daddyofsky
Re: [PHP-DEV] [RFC] Invoke __callStatic when non-static public methods are called statically
2024년 3월 30일 (토) 오전 1:21, Larry Garfield 님이 작성: > On Fri, Mar 29, 2024, at 3:33 PM, 하늘아부지 wrote: > > 2024년 3월 29일 (금) 오후 10:21, Larry Garfield 님이 작성: > >> 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 a
Re: [PHP-DEV] [RFC idea introduce] The issue where the __callStatic magic method is not called when statically calling a public method.
2024년 3월 28일 (목) 오후 6:33, Stéphane Hulard 님이 작성:
> Le jeudi 28 mars 2024 à 10:40, Claude Pache a
> écrit :
>
> >
>
> >
>
> > > Le 28 mars 2024 à 03:29, 하늘아부지 a écrit :
> > >
>
> > >
>
> > > Hi.
> > >
>
> > > I would like to register an RFC on the following issue.
> > > https://github.com/php/php-src/issues/13813
> > >
>
> > > To summarize briefly, users expect that the `__callStatic` magic
> method will be called in all cases when a method is not static while using
> the `__callStatic`. However, in reality, if the method is public, the
> `__callStatic` magic method is not called, and an error still occurs.
> > >
>
> > > I would like to hear your opinions.
> > > I also hope someone can help with the RFC registration.
> > >
>
> > >
>
> > >
> > >
>
> > > ```php
> > > > > class MyClass
> > > {
> > > public static function __callStatic($method, $args)
> > > {
> > > echo $method . "\n";
> > > }
> > >
>
> > > private function privateMethod() {}
> > > protected function protectedMethod() {}
> > > public function publicMethod() {}
> > > }
> > >
>
> > > MyClass::privateMethod();
> > > MyClass::protectedMethod();
> > > MyClass::publicMethod();
> > > ```
> > >
>
> > > Resulted in this output:
> > > ```
> > > privateMethod
> > > protectedMethod
> > > Fatal error: Uncaught Error: Non-static method MyClass::publicMethod()
> cannot be called statically in ...
> > > ```
> > >
>
> > > But I expected this output instead:
> > > ```
> > > privateMethod
> > > protectedMethod
> > > publicMethod
> > > ```
> > >
>
> > >
>
> >
>
> >
>
> > Hi,
> > One of the issue is that it is not possible to determine statically that
> a certain call is static or not. It is possible to determine it at runtime;
> but you must be careful to articulate clearly the rules. Although it is
> absolutely possible to have logical rules, I fear that they couldn’t be
> sufficiently simple in order to avoid confusion.
> >
>
> > In the following real-world (but hopefully rare) case (it is taken from
> my own codebase), I am calling a method of a grandparent class. It is *not*
> a static method:
> >
>
> > ```php
> >
>
> > foo = new class(/* ... */) extends Bar {
> >
>
> > // ...
> >
>
> > function Header() {
> > $grandparent_class = get_parent_class(parent::class);
> > $grandparent_class::Header();
> >// ... rest of code
> > }
> >
>
> >// ...
> > };
> > ```
> >
>
> > In the following more general case, I might intend to call to a static
> method. However, as of today, a call to a non-static method will occur if
> `A` has a non-static accessible method `qux()` *and* `$this` is an
> instance of `A`:
> >
>
> > ```php
> > class Foo {
> > function baz() {
> > A::qux();
> > }
> > }
> > ```
> >
>
> > (In older versions of PHP, a non-static call would occur even when
> `$this` is not an instance of `A`. Hopefully, this is no longer the case
> since PHP 8.)
> >
>
> >
>
> > —Claude
>
> Hello !
>
> In Laravel the static versus non static context is handled inside the
> different calls. So a static call on a non static method will be forwarded
> to a non static instance to be handled properly.
> I don't see any advantages to call `__callStatic` on any method call since
> the difference with `__call` is clear. Also, as Claude said, determining
> that the call is static or not is not easy.
>
> Also, building Singleton is possible using the current PHP behavior. An
> example :
>
> ```php
>
> class User
> {
> public function __callStatic($name, $arguments)
> {
> return (new static)->$name(...$arguments);
> }
>
> public static function __call($name, $arguments)
> {
> // Here handle the call the $name method.
> echo $name;
> }
> }
>
> $user = User::find(1);
> //Will output
> // find
> ```
>
> That's the way it's done in Laravel. Also note that the find method
> doesn't exists in the User object. That's why it works, the method is truly
> "magic".
> If the method is def
Re: [PHP-DEV] [RFC] Invoke __callStatic when non-static public methods are called statically
2024년 4월 1일 (월) 오전 2:31, Larry Garfield 님이 작성: > On Fri, Mar 29, 2024, at 6:12 PM, 하늘아부지 wrote: > > >> 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. > > True, but as someone else noted, Laravel already has a workaround in place > for this. WordPress is orders of magnitude more popular than Laravel, but > we don't generally design the language to work "the WordPress way," because > that is well-recognized as a not-good way to work. > > Popularity matters, but quality matters more. > > > 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. > > To be clear: I have no interest or desire to embarrass you personally. I > have never met you before so have no opinion about you one way or another, > and trust the feeling is mutual. That you're interested in improving PHP > is to your credit, and I thank you for that. > > However, that is separate from the proposal itself, which for reasons > stated I think is not a good one. That should not reflect on you > personally in any way, and is explicitly not intended as such. Certainly > I've had enough of my proposals rejected around here. :-) > > --Larry Garfield > I understand. I didn't assume my proposal would be accepted without question. I just started because I hate doing nothing. Daddyofsky
[PHP-DEV] Request for RFC karma
Hi. I request RFC karma to discuss the issue at this link. https://github.com/php/php-src/issues/13813 Wiki account : daddyofsky Regards.
[PHP-DEV] [RFC idea introduce] The issue where the __callStatic magic method is not called when statically calling a public method.
Hi. I would like to register an RFC on the following issue. https://github.com/php/php-src/issues/13813 To summarize briefly, users expect that the `__callStatic` magic method will be called in all cases when a method is not static while using the `__callStatic`. However, in reality, if the method is public, the `__callStatic` magic method is not called, and an error still occurs. I would like to hear your opinions. I also hope someone can help with the RFC registration. ```php
[PHP-DEV] [RFC] Invoke __callStatic when non-static public methods are called statically
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
Re: [PHP-DEV] [RFC] Invoke __callStatic when non-static public methods are called statically
2024년 3월 29일 (금) 오후 5:43, Stéphane Hulard 님이 작성: > Le vendredi 29 mars 2024 à 03:39, 하늘아부지 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
