Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122820
Precedence: bulk
MIME-Version: 1.0
References: <CAKkgovQcibHLQibK44wtcEbi-oKVQ5ifCiZPgN8SR2RCg5yMGQ@mail.gmail.com>
 <CAPzBOBM5LMNBJt+qAsKOX+W17jRjnYHKyqRyBs69=u8Bdx-KAw@mail.gmail.com> <CAKkgovRG2rYLRD3Wwz7qiC+jxNUfYMpiBCCGrZjmqfnzuS92GA@mail.gmail.com>
In-Reply-To: <CAKkgovRG2rYLRD3Wwz7qiC+jxNUfYMpiBCCGrZjmqfnzuS92GA@mail.gmail.com>
Date: Sat, 30 Mar 2024 11:28:24 +0100
Message-ID: <CAPzBOBNaKjep+Guun_9De_vyYsSqb316H0vdiz7AWy6fcbgKqg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Invoke __callStatic when non-static public
 methods are called statically
To: =?UTF-8?B?7ZWY64qY7JWE67aA7KeA?= <daddyofsky@gmail.com>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: landers.robert@gmail.com (Robert Landers)

On Sat, Mar 30, 2024 at 1:06=E2=80=AFAM =ED=95=98=EB=8A=98=EC=95=84=EB=B6=
=80=EC=A7=80 <daddyofsky@gmail.com> wrote:
>
>
>
> 2024=EB=85=84 3=EC=9B=94 30=EC=9D=BC (=ED=86=A0) =EC=98=A4=EC=A0=84 2:15,=
 Robert Landers <landers.robert@gmail.com>=EB=8B=98=EC=9D=B4 =EC=9E=91=EC=
=84=B1:
>>
>> On Fri, Mar 29, 2024 at 3:41=E2=80=AFAM =ED=95=98=EB=8A=98=EC=95=84=EB=
=B6=80=EC=A7=80 <daddyofsky@gmail.com> 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 f=
eature cannot be used.
>>
>> This sounds like a bug or feature request with your IDE, not a problem w=
ith PHP.
>>
>> > This code is very clear, aside from the fact that the method is not st=
atic.
>>
>> 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 featur=
e 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 si=
ngle 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 na=
vigation 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 coul=
d suggest how to fix the problematic parts.
>
> Using the example of the IDE meant to illustrate that it should be intuit=
ive enough for the IDE to find it directly.
>
> Even currently, `__callStatic` is called in cases of non-static methods t=
hat 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 wit=
hout actually causing much magic. The current `__callStatic` is like a magi=
cian 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 als=
o be beneficial to provide users with options to do other things, specifica=
lly when they intentionally use `__callStatic`. That's the core point of th=
is proposal.
>
> If there are better examples or ways to explain, I would appreciate learn=
ing about them.
>
> Daddyofsky

My main issue with the RFC comes down to the fact that it suggests
that this is valid:

// https://3v4l.org/0ufkt
class Test {
  public function test() {}
  public static function test() {}
}

Having two functions with the same name, one static and one non-static
is (currently) an error. Allowing callStatic to break this rule
without being able to write the above code, feels inconsistent. While
PHP is full of inconsistencies, adding more of them isn't the right
way. I'd much rather see static and non-static methods being able to
have the same name -- in which case it would make sense for callStatic
to work as described in the RFC.

Robert Landers
Software Engineer
Utrecht NL