Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:122812 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 6B8DB1A009C for ; Fri, 29 Mar 2024 23:12:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1711753980; bh=NwMI4qTYbos6hWAHTi5sQ4kpaVLbl7X32JDuZ2InWH8=; h=References:In-Reply-To:From:Date:Subject:To:From; b=P+5wB8S9/rlmqe0TRHm7gmi2MziLMY+ZiLj/V/dU/hBsXCSG/Lrf+1JKuWrTWgkWT 6YURM369XXJZw17J6Z0z0GmUaGTiAD37lqgmsmLdvQJPxHoDI6WYukNHQ1Zi9GsW75 bIe3OtTA5p7MS1RdVDrpo1aRoBSAPweRxCTx7OgyIWNgr3jRdSINa+teWy5+7vHh82 uPzBPhNf/fzA2na0gOMPf8IxvHDPzXfdNmPSKEY7OoFY8ysvX8BX/jNSJZ9OojA5SI ooUZdcu2pD4TXRABzTJX+VbWiIJJ4mre9sMOhyNmadEpRhf2op0OjoF8tcPM6DAUff oEdI+GiXBYqFQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 2A7D218005F for ; Fri, 29 Mar 2024 23:12:59 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: ** X-Spam-Status: No, score=2.1 required=5.0 tests=BAYES_50,BODY_8BITS, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS, FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com [209.85.219.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 29 Mar 2024 23:12:58 +0000 (UTC) Received: by mail-yb1-f170.google.com with SMTP id 3f1490d57ef6-dc6d8bd618eso2347779276.3 for ; Fri, 29 Mar 2024 16:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711753952; x=1712358752; darn=lists.php.net; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=w2G9IBdCQkAlPAlorMlZx8VHhsqAQ75HDnlsBZTUvAE=; b=l2uFOpO3hqv5FYocIAWWKlxZSMCK1ZnZ8EilPy31hQtZcLmp9sh4Ue1Phz6SOmdJoB DxgoQajGeQisg+mCu7RNkx/xP1xK2o0bNWz9kwDvm+8tQMPDL/bMaiHkIXFarVFqmdBk jO1fwClnYwYZnyZd1pG2i/SjcFn2gRBV3Bb8PNAMqxqEqbDHyk1Hho2/eRA5mGbgumkP GJWo+lkj8FAxY7TTvPpEuzwr9MhGI4VE60idBV0RNE5/QiFfGb9V9u5ev4rrujZwzN8I eUHQKj6P7PSlkagtNo2ZYCoyuB9+E2i1if7pevYe7qmxGudQujFzBnXVynClyvHwBYrx PJ8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711753952; x=1712358752; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=w2G9IBdCQkAlPAlorMlZx8VHhsqAQ75HDnlsBZTUvAE=; b=eiWJglnuql8fBSG3WoDMY/VKkx3Qz8Kg8SVimcq1e2kRAL27n1yFISR4CbLR+3o41j 9hVxjx76bQQqjH3h2NJjfyyu1byTFxNC7uV0SMRR2gEgZGfEBdiBUzJkgNECuXpaFGsN uIb32yQMXEjsLs227IC/BuJQKkCWffr0iU/AzjA6/RZy4hJrRzigxKUWl1GxQnvJ2Kmr uvDSXmhnkh6c7DbWN0YC6dvhUTqvHZwAIokt7sfu4oU7rxqgUWThwoRNI+kLw2VD4Nnl 8jLwi2hgoICXSzNJXgF8sSa7AI67vBMtoRvs9l+BBup49O7iHPTx/e2qykTSIuYso280 AhmA== X-Forwarded-Encrypted: i=1; AJvYcCX93Jabv1ZzpsnW+5xUiUrKs9fk6Qd/79GrAg65FLMtZO0rqxrUQgOPwZA60SV7abfDBiWt5+StfICTQjjhHBDnCKXh+A0NRQ== X-Gm-Message-State: AOJu0YxPI/wbKhKhoKjfozCsx7DrebXGl92/BO5yqUz5GT87lFWI1hli sdCGOCZ7ddL1l/xxAyiPcbZXldwni8grdJXjQOAzGidvE6RNH/yjFik0Mp5mNw924B28uIoD5UK AxwH92mv8yYypFV9MIgxn9GXnQkS+pHaLJlq6KOmo X-Google-Smtp-Source: AGHT+IEZPau14qGQECgUC3ecHmYeUcY597bXIxTVVurKzaZcrHydBivcUY1qpqFWOh2RbRSSMWFOV3it7FsBWeG/Z+c= X-Received: by 2002:a25:fc0f:0:b0:dcc:4cdc:e98f with SMTP id v15-20020a25fc0f000000b00dcc4cdce98fmr3329499ybd.34.1711753951630; Fri, 29 Mar 2024 16:12:31 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 References: In-Reply-To: Date: Sat, 30 Mar 2024 07:12:20 +0800 Message-ID: Subject: Re: [PHP-DEV] [RFC] Invoke __callStatic when non-static public methods are called statically To: Larry Garfield , internals@lists.php.net Content-Type: multipart/alternative; boundary="0000000000003ae51d0614d4c6ac" From: daddyofsky@gmail.com (=?UTF-8?B?7ZWY64qY7JWE67aA7KeA?=) --0000000000003ae51d0614d4c6ac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2024=EB=85=84 3=EC=9B=94 30=EC=9D=BC (=ED=86=A0) =EC=98=A4=EC=A0=84 1:21, L= arry Garfield =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1= : > 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 =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 > Laravel projects. (I am far from the only person to argue this; many eve= n > 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? > > Developers also bring to life horrible monstrosities that are an afront t= o > all that is holy. I am a developer. It's what we do. :-) Especially wh= en > VC money is involved. > > Not all "innovation" is good. > > > 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. > > It simplifies a practice that should not be a practice in the first > place. That's not a net-win. > > > 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? > > 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 > Hi. > It would be more accurate to say "calling non-static methods in a static-like manner is common *in Laravel* It might be correct to say that this is specific to Laravel. The problem, however, is that Laravel is used so extensively that it cannot be ignored. There's a point of embarrassing me. It's as if my proposal, if accepted, would create problems that did not previously exist. Yet, the existence of `__callStatic` already allows for the issues you've pointed out to occur. You can already write code like `foo::bar()::baz()` with the current PHP. The possibility of more problems arising could indeed be true. In that sense, I understand your point. And unless `__callStatic` is intentionally used, calling non-static methods statically will still result in an error, just as it does now. I am simply proposing to give users the choice when they intentionally use `__callStatic`. Daddyofsky --0000000000003ae51d0614d4c6ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
2024=EB=85=84 3=EC=9B=94 30=EC=9D=BC = (=ED=86=A0) =EC=98=A4=EC=A0=84 1:21, Larry Garfield <larry@garfieldtech.com>=EB=8B=98=EC=9D=B4 =EC= =9E=91=EC=84=B1:
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_cal= lstatc_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.=C2=A0 Calling non-static me= thods 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.=C2=A0 Static methods are methods *on a type*.=C2=A0= Non-static methods are methods *on an instance*.=C2=A0 Those are not the s= ame 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" system serves as a poorly designed, hard to debug, har= d to test, archaic alternative to using dependency injection.=C2=A0 While t= here may have once been an argument that DI was "too hard" for si= mple cases a decade ago or more (though even then I think it was a bade tra= de-off), the combination of auto-wiring DI Containers (which Laravel pionee= red in PHP) and constructor promotion (introduced in PHP 8.0, 3.5 years ago= .) completely eliminates those arguments.=C2=A0 The level of effort to do a= ctual DI today is trivially small, and the benefits over magic hidden globa= ls are massive.
>>
>> 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 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 ar= gue harmful for the language.=C2=A0 On the contrary, I would favor going th= e other direction: Calling a static method as though it were non-static cur= rently works, and I would support making that an error, to further emphasiz= e that static and non-static methods are not interchangeable.
>>
>> [1] https://peakd.com/hive-1= 68588/@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 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 =
> 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&#= 39;t
> think this is necessarily a bad thing. Isn't it developers who bri= ng to
> life ingenious ideas that were unforeseen?

Developers also bring to life horrible monstrosities that are an afront to = all that is holy.=C2=A0 I am a developer.=C2=A0 It's what we do. :-)=C2= =A0 Especially when VC money is involved.

Not all "innovation" is good.

> 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. <= br> > It's like taking a longer route because the road is blocked, or > creating a dog door because the main door is closed.

It simplifies a practice that should not be a practice in the first place.= =C2=A0 That's not a net-win.

> 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?

I don't actually work on the PHP engine, I just write RFC text for othe= r people; I have ~25 years of experience writing user-space PHP.=C2=A0 And = no, anything involving stealth globals via statics is the opposite of "= ;more convenient and cleaner."

--Larry Garfield

Hi.

= > It would be more accurate to say "calling non-static methods in a= static-like manner is common *in Laravel*

It might be correct to s= ay that this is specific to Laravel. The problem, however, is that Laravel = is used so extensively that it cannot be ignored.

There's a poin= t of embarrassing me. It's as if my proposal, if accepted, would create= problems that did not previously exist. Yet, the existence of `__callStati= c` already allows for the issues you've pointed out to occur. You can a= lready write code like `foo::bar()::baz()` with the current PHP. The possib= ility of more problems arising could indeed be true. In that sense, I under= stand your point.

And unless `__callStatic` is int= entionally used, calling non-static methods statically will still result in= an error, just as it does now.
I am simply proposing to give users the = choice when they intentionally use `__callStatic`.

Daddyo= fsky
--0000000000003ae51d0614d4c6ac--