Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122803
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: <bbbb6db9-f62b-4b2f-aa37-4d7193b96b09@app.fastmail.com>
In-Reply-To: 
 <CAKkgovQcibHLQibK44wtcEbi-oKVQ5ifCiZPgN8SR2RCg5yMGQ@mail.gmail.com>
References: 
 <CAKkgovQcibHLQibK44wtcEbi-oKVQ5ifCiZPgN8SR2RCg5yMGQ@mail.gmail.com>
Date: Fri, 29 Mar 2024 13:03:55 +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 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 c=
onfusing, but in modern PHP, it has already become common practice.=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 should n=
ever 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" sy=
stem serves as a poorly designed, hard to debug, hard to test, archaic a=
lternative 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 mo=
re (though even then I think it was a bade trade-off), the combination o=
f auto-wiring DI Containers (which Laravel pioneered in PHP) and constru=
ctor promotion (introduced in PHP 8.0, 3.5 years ago.) completely elimin=
ates those arguments.  The level of effort to do actual DI today is triv=
ially small, and the benefits over magic hidden globals are massive.

Laravel Facades are a relic of an older time best avoided, even in Larav=
el projects.  (I am far from the only person to argue this; many even wi=
thin Laravel's inner community make this argument.)

Adding features to the language that seemingly exist only to make that p=
articular 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 oth=
er direction: Calling a static method as though it were non-static curre=
ntly works, and I would support making that an error, to further emphasi=
ze that static and non-static methods are not interchangeable.

[1] https://peakd.com/hive-168588/@crell/cutting-through-the-static

--Larry Garfield