Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122804
Precedence: bulk
MIME-Version: 1.0
References: <CAKkgovQcibHLQibK44wtcEbi-oKVQ5ifCiZPgN8SR2RCg5yMGQ@mail.gmail.com>
 <bbbb6db9-f62b-4b2f-aa37-4d7193b96b09@app.fastmail.com>
In-Reply-To: <bbbb6db9-f62b-4b2f-aa37-4d7193b96b09@app.fastmail.com>
Date: Fri, 29 Mar 2024 23:33:31 +0800
Message-ID: <CAKkgovSgY9-XXKjfQ2_nGoHEcnBMsG3zODwqHdMzW52s0o9tBw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Invoke __callStatic when non-static public
 methods are called statically
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000660f790614ce5d5e"
From: daddyofsky@gmail.com (=?UTF-8?B?7ZWY64qY7JWE67aA7KeA?=)

--000000000000660f790614ce5d5e
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 10:21, =
Larry Garfield <larry@garfieldtech.com>=EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=
=B1:

> On Fri, Mar 29, 2024, at 2:39 AM, =ED=95=98=EB=8A=98=EC=95=84=EB=B6=80=EC=
=A7=80 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 "facade=
s"
> system serves as a poorly designed, hard to debug, hard to test, archaic
> alternative to using dependency injection.  While there may have once bee=
n
> 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 constructo=
r
> 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 Larave=
l
> 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 tha=
t
> 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

--000000000000660f790614ce5d5e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></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 10:21, Larry Garfield &lt;<a href=3D"mailto:=
larry@garfieldtech.com">larry@garfieldtech.com</a>&gt;=EB=8B=98=EC=9D=B4 =
=EC=9E=91=EC=84=B1:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">On Fri, Mar 29, 2024, at 2:39 AM, =ED=95=98=EB=8A=98=EC=95=84=EB=B6=80=
=EC=A7=80 wrote:<br>
&gt; Hello.<br>
&gt;<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; I look forward to your interest and advice.<br>
<br>
I am firmly against this proposal.<br>
<br>
I think my objection boils down to this line in the RFC:<br>
<br>
&gt; Of course, calling non-static methods in a static-like manner can be c=
onfusing, but in modern PHP, it has already become common practice. <br>
<br>
I would argue this statement is false.=C2=A0 Calling non-static methods in =
a static-like manner is confusing, which is why in modern PHP one should ne=
ver do that, and respect that static and non-static methods exist in a sepa=
rate universe.=C2=A0 Static methods are methods *on a type*.=C2=A0 Non-stat=
ic methods are methods *on an instance*.=C2=A0 Those are not the same thing=
.[1]<br>
<br>
It would be more accurate to say &quot;calling non-static methods in a stat=
ic-like manner is common *in Laravel*,&quot; where the badly-named &quot;fa=
cades&quot; system serves as a poorly designed, hard to debug, hard to test=
, archaic alternative to using dependency injection.=C2=A0 While there may =
have once been an argument that DI was &quot;too hard&quot; for simple case=
s 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 PH=
P) and constructor promotion (introduced in PHP 8.0, 3.5 years ago.) comple=
tely eliminates those arguments.=C2=A0 The level of effort to do actual DI =
today is trivially small, and the benefits over magic hidden globals are ma=
ssive.<br>
<br>
Laravel Facades are a relic of an older time best avoided, even in Laravel =
projects.=C2=A0 (I am far from the only person to argue this; many even wit=
hin Laravel&#39;s inner community make this argument.)<br>
<br>
Adding features to the language that seemingly exist only to make that part=
icular buggy hack easier to do is a step backwards, and I would argue harmf=
ul for the language.=C2=A0 On the contrary, I would favor going the other d=
irection: Calling a static method as though it were non-static currently wo=
rks, and I would support making that an error, to further emphasize that st=
atic and non-static methods are not interchangeable.<br>
<br>
[1] <a href=3D"https://peakd.com/hive-168588/@crell/cutting-through-the-sta=
tic" rel=3D"noreferrer" target=3D"_blank">https://peakd.com/hive-168588/@cr=
ell/cutting-through-the-static</a><br>
<br>
--Larry Garfield<br></blockquote><div><br></div><div><div>Thank you for you=
r feedback.</div><div>I agree that static and non-static should be distinct=
, which is a given.<br> <br>There are a few points I&#39;d like to make.<br=
> <br>First,
 my proposed RFC is not about allowing non-static methods to be used=20
statically. Although all my examples use `::`, they internally operate=20
on an instance. Inside `__callStatic`, an instance is created and used=20
for operations.<br><br>Second, as already possible through the=20
`__callStatic` method, non-static methods can be called as if they were=20
static (as mentioned, this does not mean they operate statically). For=20
protected and private methods, the `__callStatic` function is invoked=20
even for non-static methods. This might not be to everyone&#39;s liking, an=
d
 to others, it might be a favorite feature. It might operate differently
 from the initial intention when `__callStatic` was introduced. However,
 I don&#39;t think this is necessarily a bad thing. Isn&#39;t it developers=
 who=20
bring to life ingenious ideas that were unforeseen?<br> <br>Third, as=20
you can see from my examples, what I propose could be a solution to the=20
current issues. Since it does not work for public methods while it does=20
for protected and private ones, it has led to code becoming more obscure
 and layered through facade-like patterns. It&#39;s like taking a longer=20
route because the road is blocked, or creating a dog door because the=20
main door is closed.<br><br>From the perspective of those who develop the P=
HP language itself, my proposal might not be appealing. However, I=20
believe from the user&#39;s standpoint, my proposal could lead to more=20
convenient and cleaner coding practices. Didn&#39;t PHP start as a language=
=20
meant to be user-friendly? <br><br></div><div>Regards<br></div><div>Daddyof=
sky</div>=C2=A0</div></div></div>

--000000000000660f790614ce5d5e--