Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122805
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-333-gbfea15422e-fm-20240327.001-gbfea1542
Precedence: bulk
MIME-Version: 1.0
Message-ID: <a1041fae-d72d-4b46-a216-580dc3a9062a@app.fastmail.com>
In-Reply-To: 
 <CAKkgovSgY9-XXKjfQ2_nGoHEcnBMsG3zODwqHdMzW52s0o9tBw@mail.gmail.com>
References: 
 <CAKkgovQcibHLQibK44wtcEbi-oKVQ5ifCiZPgN8SR2RCg5yMGQ@mail.gmail.com>
 <bbbb6db9-f62b-4b2f-aa37-4d7193b96b09@app.fastmail.com>
 <CAKkgovSgY9-XXKjfQ2_nGoHEcnBMsG3zODwqHdMzW52s0o9tBw@mail.gmail.com>
Date: Fri, 29 Mar 2024 15:49:14 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Invoke __callStatic when non-static public methods are
 called statically
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Mar 29, 2024, at 3:33 PM, =ED=95=98=EB=8A=98=EC=95=84=EB=B6=80=EC=
=A7=80 wrote:
> 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.
>>=20
>> I am firmly against this proposal.
>>=20
>> I think my objection boils down to this line in the RFC:
>>=20
>> > Of course, calling non-static methods in a static-like manner can b=
e confusing, but in modern PHP, it has already become common practice.=20
>>=20
>> 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 shoul=
d never do that, and respect that static and non-static methods exist in=
 a separate universe.  Static methods are methods *on a type*.  Non-stat=
ic methods are methods *on an instance*.  Those are not the same thing.[=
1]
>>=20
>> It would be more accurate to say "calling non-static methods in a sta=
tic-like manner is common *in Laravel*," where the badly-named "facades"=
 system serves as a poorly designed, hard to debug, hard to test, archai=
c 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 combinatio=
n of auto-wiring DI Containers (which Laravel pioneered in PHP) and cons=
tructor promotion (introduced in PHP 8.0, 3.5 years ago.) completely eli=
minates those arguments.  The level of effort to do actual DI today is t=
rivially small, and the benefits over magic hidden globals are massive.
>>=20
>> Laravel Facades are a relic of an older time best avoided, even in La=
ravel projects.  (I am far from the only person to argue this; many even=
 within Laravel's inner community make this argument.)
>>=20
>> Adding features to the language that seemingly exist only to make tha=
t particular buggy hack easier to do is a step backwards, and I would ar=
gue harmful for the language.  On the contrary, I would favor going the =
other direction: Calling a static method as though it were non-static cu=
rrently works, and I would support making that an error, to further emph=
asize that static and non-static methods are not interchangeable.
>>=20
>> [1] https://peakd.com/hive-168588/@crell/cutting-through-the-static
>>=20
>> --Larry Garfield
>
> Thank you for your feedback.
> I agree that static and non-static should be distinct, which is a give=
n.
>
> There are a few points I'd like to make.
>
> First, my proposed RFC is not about allowing non-static methods to be=20
> used statically. Although all my examples use `::`, they internally=20
> operate on an instance. Inside `__callStatic`, an instance is created=20
> and used for operations.
>
> Second, as already possible through the `__callStatic` method,=20
> non-static methods can be called as if they were static (as mentioned,=20
> this does not mean they operate statically). For protected and private=20
> methods, the `__callStatic` function is invoked even for non-static=20
> methods. This might not be to everyone's liking, and to others, it=20
> might be a favorite feature. It might operate differently from the=20
> initial intention when `__callStatic` was introduced. However, I don't=20
> think this is necessarily a bad thing. Isn't it developers who bring t=
o=20
> 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. :-)  Especiall=
y when VC money is involved.

Not all "innovation" is good.

> Third, as you can see from my examples, what I propose could be a=20
> solution to the current issues. Since it does not work for public=20
> methods while it does for protected and private ones, it has led to=20
> code becoming more obscure and layered through facade-like patterns.=20
> It's like taking a longer route because the road is blocked, or=20
> creating a dog door because the main door is closed.

It simplifies a practice that should not be a practice in the first plac=
e.  That's not a net-win.

> From the perspective of those who develop the PHP language itself, my=20
> proposal might not be appealing. However, I believe from the user's=20
> standpoint, my proposal could lead to more convenient and cleaner=20
> coding practices. Didn't PHP start as a language meant to be=20
> user-friendly?=20

I don't actually work on the PHP engine, I just write RFC text for other=
 people; I have ~25 years of experience writing user-space PHP.  And no,=
 anything involving stealth globals via statics is the opposite of "more=
 convenient and cleaner."

--Larry Garfield