Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122802
Precedence: bulk
MIME-Version: 1.0
References: <CAKkgovQcibHLQibK44wtcEbi-oKVQ5ifCiZPgN8SR2RCg5yMGQ@mail.gmail.com>
 <HQP-nIjJQFNP4ZkC5eZE_q8g3GqO9MROfzMev_jysNQTr_EezCfeiHJT6pmwmpSu0uCeNCivUD5ot3uFxwS9J1XCXoKx5P96rDwuwdb6UBo=@chstudio.fr>
In-Reply-To: <HQP-nIjJQFNP4ZkC5eZE_q8g3GqO9MROfzMev_jysNQTr_EezCfeiHJT6pmwmpSu0uCeNCivUD5ot3uFxwS9J1XCXoKx5P96rDwuwdb6UBo=@chstudio.fr>
Date: Fri, 29 Mar 2024 18:43:39 +0800
Message-ID: <CAKkgovSFv=GzDPgh_Z8DfnvqD8m+1C-Ru4xwduP_LcBTFWhnhg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Invoke __callStatic when non-static public
 methods are called statically
To: =?UTF-8?Q?St=C3=A9phane_Hulard?= <s.hulard@chstudio.fr>, 
	internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000b32f600614ca503f"
From: daddyofsky@gmail.com (=?UTF-8?B?7ZWY64qY7JWE67aA7KeA?=)

--000000000000b32f600614ca503f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

2024=EB=85=84 3=EC=9B=94 29=EC=9D=BC (=EA=B8=88) =EC=98=A4=ED=9B=84 5:43, S=
t=C3=A9phane Hulard <s.hulard@chstudio.fr>=EB=8B=98=EC=9D=B4 =EC=9E=91=EC=
=84=B1:

> Le vendredi 29 mars 2024 =C3=A0 03:39, =ED=95=98=EB=8A=98=EC=95=84=EB=B6=
=80=EC=A7=80 <daddyofsky@gmail.com> a =C3=A9crit :
>
> > 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 g=
o
> 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 R=
FC
> 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 b=
y
> 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 forward=
ed
> 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=C3=A9phane


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

--000000000000b32f600614ca503f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"></div><br><div class=3D"gmail_quote"><div=
 dir=3D"ltr" class=3D"gmail_attr">2024=EB=85=84 3=EC=9B=94 29=EC=9D=BC (=EA=
=B8=88) =EC=98=A4=ED=9B=84 5:43, St=C3=A9phane Hulard &lt;<a href=3D"mailto=
:s.hulard@chstudio.fr">s.hulard@chstudio.fr</a>&gt;=EB=8B=98=EC=9D=B4 =EC=
=9E=91=EC=84=B1:<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
>Le vendredi 29 mars 2024 =C3=A0 03:39, =ED=95=98=EB=8A=98=EC=95=84=EB=B6=
=80=EC=A7=80 &lt;<a href=3D"mailto:daddyofsky@gmail.com" target=3D"_blank">=
daddyofsky@gmail.com</a>&gt; a =C3=A9crit=C2=A0:<br>
<br>
&gt; Hello.<br>
&gt; <br>
<br>
&gt; I created a wiki for __callStatic related issues.<br>
&gt; Please see:<br>
&gt; <a href=3D"https://wiki.php.net/rfc/complete_callstatc_magic" rel=3D"n=
oreferrer" target=3D"_blank">https://wiki.php.net/rfc/complete_callstatc_ma=
gic</a><br>
&gt; <br>
<br>
&gt; I look forward to your interest and advice.<br>
&gt; <br>
<br>
&gt; Best Regards.<br>
&gt; Daddyofsky<br>
<br>
Hello !<br>
<br>
I took a look at your proposal and I think about important issues if we go =
this way.<br>
<br>
A static method mustn&#39;t used the `$this` variable because it simply doe=
sn&#39;t exists in the static context. The examples you&#39;re adding in th=
e RFC are fine but they always rely to a specific `__callStatic` implementa=
tion that will use a new instance of the object to forward the call.<br>
<br>
There are multiple cases where it&#39;ll be complicated to use it this way.=
 Two of them I have in mind:<br>
<br>
- What if the object needs important parameters in its constructor that are=
n&#39;t available in the static context ? Or those parameters need to be in=
itialized outside of the `__callStatic` method?<br>
- What if the underlying non static method we are trying to invoke is using=
 the `$this` variable?<br>
<br>
In those two examples, I would prefer having a fatal error that explains th=
at I&#39;m not doing the call correctly (calling a non static method in the=
 static context) to ensure it&#39;ll be easy to understand and fix.<br>
<br>
The use cases you are describing here have been fixed in the user space by =
the Laravel team. It&#39;s a very specific way of working that&#39;s mostly=
 specific to Laravel.<br>
<br>
For sure it makes the code harder to read since you can&#39;t jump to a rea=
l method easily (because most of the methods are magic ones and are forward=
ed to underlying objects). I don&#39;t tell it&#39;s wrong but I&#39;m not =
sure it&#39;s relevant to make the whole language simplify this process.<br=
>
<br>
If there is a way to work correctly with those static vs non static calls a=
nd capture relevant errors to expose them to users, that&#39;s fine.<br>
<br>
However, I think this is an important behavior change because it&#39;ll all=
ow a new way to work with method that were forbidden before.<br>
<br>
Regards<br>
St=C3=A9phane</blockquote><div><br></div><div>Hello.<br></div><div><br>Than=
k you for your interest.</div><div>In fact, `__callStatic` is often used fo=
r static-like singletons, and such examples are likely to be the majority.<=
br><br>Regarding the two issues you pointed out, the first can be resolved =
by adding an initialization method like `init`. It&#39;s common to use a se=
parate initialization function when dealing with general class operations, =
especially when there is a lot to initialize.<br><br>The second issue is ac=
tually the same problem that exists today. Since `__callStatic` is called i=
n the case of static calls to private or protected methods, the use of `$th=
is` is not exclusive to public methods. In other words, the `$this` issue a=
pplies the same way it does now. Allowing public methods does not create a =
problem that didn&#39;t exist before.<br><br>If it had been the case that c=
alling non-static methods statically always resulted in an error, the issue=
s you raised would have been significant. However, private and protected me=
thods can already be called without error. Even if this RFC is not accepted=
, the points you mentioned still apply.</div><div>=C2=A0<br></div><div>Rega=
rds<br></div><div>Daddyofsky<br></div></div></div>

--000000000000b32f600614ca503f--