Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:122813 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 1EE201A009C for ; Sat, 30 Mar 2024 00:07:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1711757245; bh=T5YfCb11WKFGgWU4cTHheo74vXP2dWC9HyJ3/MKOPlg=; h=References:In-Reply-To:From:Date:Subject:To:From; b=RNxcHhdNDgSfO4niuyWOswAw7Sz04Wxgg0Kb6s+wmiLajUWD1OtZH3x3Si45bjw6B FtJnyo9RTlMg73hNk9dY3+Zhv5Qeq3P3gx6Bah+6t9plVRzbfM7Mv6FsCSydfo7EGu DBWhFZXlL/EN8bd4PAgfT8myGdGND/PTJc1kMduvO7xDl56gZw5YF2hCKyY4KhQoDN JCGIVwlNhzqLcjUNgrSB9Ks8296OGJDTRppwATP8/diSraLrudw/BnNzXety9H7AxS qVahnXsEVOjDWfd94KYW+CsFd5ml9Kap5QhxNC+5xwviCa03mPcKA+6KK6veD8HHhn GGGaagTayQ8lg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B0109180691 for ; Sat, 30 Mar 2024 00:07:24 +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-yw1-f172.google.com (mail-yw1-f172.google.com [209.85.128.172]) (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 ; Sat, 30 Mar 2024 00:07:24 +0000 (UTC) Received: by mail-yw1-f172.google.com with SMTP id 00721157ae682-60a068e26d8so25017147b3.3 for ; Fri, 29 Mar 2024 17:06:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711757217; x=1712362017; 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=MMjUyj3+HC9rGW97wg/Hib5k244/CiZuA9nLbqZGJ70=; b=W2pTNIJRQLa24ULTnm4gSw77hVGSOobnXu1yfOcBpw7wOd0/rx3u47u9kMgVWCu8gg qLaJyj1TmfIYHX9p7z3VHSlGxvYKTffdfdkqsQ49FszTbWQHiq5FPFP7x8+rFzkKDI0W ydui76B3tFExfwzmlIg4WqxjZWpvZIlgCHGPD2piGDZrQDzme2R/wTHVqmctr4Ddmkgf en7aR3C7/6YnWbaJP0TpwzI7wrj7V4ki1AjkWAgnBG2QSWCulMkVebFXWShgye/zPdzY Slm5Gm7YNgDnOuxQmVUHISW2nDJoVK3p3zY/Mi+U2Quogwj4IRpgBEfljuhi9ozF/Nwe 9+Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711757217; x=1712362017; 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=MMjUyj3+HC9rGW97wg/Hib5k244/CiZuA9nLbqZGJ70=; b=kF4wYgmB01s+HdndqM1iphhlhO5SFddjd+LBm+QUWyecLRBkBvRs5miGRmlONQDOOM 8l0ACU+wDGg9PKLmmL4BZb/B54yHxvhKCygFHlpfvCTkICo/MaJPeNBW8piJ8aKwAgEC Y5g5b1hgXUoVpMDYMpFwuT/myCvLPqp6irOo8UjF3O6aGsaXGZwr6uymhSoBIDi3C7me BBCMNd16XocqpVXKyXjysZxLZH2D5W2Qqyn7GLADvhlsORt/lrDswEjd+EQcMbMem6uB 0P5jqYtFnDiNxohvaL/SivYJB5Q5n1hpdC5E0sKY8shJZ4tn1lr0MUlHkuY+rQabgINI /uVQ== X-Forwarded-Encrypted: i=1; AJvYcCV5bPzs5dDDECLL5VSTd9x/FUXFpz0ja8savUiqRhFFSdwYabTw6RFElg0wh5MS6vt5Mt7EMz15O//eWhG9lcoODM6AgyjojQ== X-Gm-Message-State: AOJu0YxzKjo37apf/7y0e0OZs04OQR03MuwoYulvLNYDb+9yRX+HwyJp 7KwlH3reU1u6MhqpbtKFCfC3Lsq/Ah/Tw01OGkLZKRJfMAXcJbg80QF1xbqzb6nusqL/QiNahz9 KaCN66IG2M6N3ma/9elan0eNz5nM= X-Google-Smtp-Source: AGHT+IFKhvXOtaJKDiXzpMGUyDBZOZCpOsijyEQiM8f6I357QuXZDKOwmDOxpvXS0DuVg5K/k553UCXeE+rCpx59H6o= X-Received: by 2002:a25:9109:0:b0:dcd:b76f:36de with SMTP id v9-20020a259109000000b00dcdb76f36demr3659101ybl.1.1711757217395; Fri, 29 Mar 2024 17:06:57 -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 08:06:46 +0800 Message-ID: Subject: Re: [PHP-DEV] [RFC] Invoke __callStatic when non-static public methods are called statically To: Robert Landers , internals@lists.php.net Content-Type: multipart/alternative; boundary="000000000000e27d7c0614d5884c" From: daddyofsky@gmail.com (=?UTF-8?B?7ZWY64qY7JWE67aA7KeA?=) --000000000000e27d7c0614d5884c 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 2:15, R= obert Landers =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84= =B1: > On Fri, Mar 29, 2024 at 3:41=E2=80=AFAM =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. > > > > Best Regards. > > Daddyofsky > > Hey there, > > Some general feedback: > > The RFC is a bit hard for me to follow, for example: > > > However, the IDE cannot find active method, and the Go to Definition > feature cannot be used. > > This sounds like a bug or feature request with your IDE, not a problem > with PHP. > > > This code is very clear, aside from the fact that the method is not > static. > > Clear to whom? As a developer this looks downright confusing. I can't > even guess what the actual behavior is. If you call a non-static > method statically, its currently an error. Why would this not be an > error? > > > The IDE recognizes active methods well and the Go to definition feature > also works properly. > > What is stopping the IDE to taking you to the __callStatic method? > That would be the correct behavior IMHO, not the implementation for > instance methods. > > > Even if there are only a few core methods, it cannot be made into a > single file. > > There is nothing stopping you from putting multiple classes in a file. > > > As can be seen in the above examples, the code becomes clearer, and > navigation through the IDE works much better. > > I completely disagree. It mixes concerns and makes spaghetti code into > incomprehensible code. Also, maybe you should take up IDE navigation > with your IDE? > > > Instead of throwing an error when a non-static public method is called > statically, the _ _callStatic method should be invoked. > > I completely agree with this, btw. Your examples could use some work > and shows all the reasons why it shouldn't call __callStatic(). A real > life example, that has nothing to do with a specific framework: > > When generating proxies for existing types, you often need to share > some state between the proxies. To do that, you put static > methods/properties on the proxy class and hope to the PHP Gods that > nobody will ever accidentally name something in their concrete class > with the name you chose for things. To help with that, you create some > kind of insane prefix. If __callStatic() were called ALWAYS in a > static context, even if a non-static method exists, then collisions > would literally be impossible. But at that point, why can't I just > write: > > class Test { > public static function test(): string { return "hello world"; } > public function test(): int { return random_int(); } > } > > ??? I feel like this is your real RFC and should be allowed if we're > allowed to __callStatic() to instance methods. I don't think it makes > sense to have one without the other, and then what you want with > __callStatic() comes naturally, instead of this weird and confusing > RFC. > > > Robert Landers > Software Engineer > Utrecht NL > Hello. I'm not very familiar with documentation. It would be helpful if you could suggest how to fix the problematic parts. Using the example of the IDE meant to illustrate that it should be intuitive enough for the IDE to find it directly. Even currently, `__callStatic` is called in cases of non-static methods that are not public methods. `__callStatic` already acts as a rule-breaker. It seems like there's a desire for the magic method to be named as such without actually causing much magic. The current `__callStatic` is like a magician who can use high-level magic to hit targets behind doors or invisible targets but can't use basic magic to hit a visible door. While it's good that the PHP kindly notifies errors, I think it would also be beneficial to provide users with options to do other things, specifically when they intentionally use `__callStatic`. That's the core point of this proposal. If there are better examples or ways to explain, I would appreciate learning about them. Daddyofsky --000000000000e27d7c0614d5884c 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 2:15, Robert Landers <landers.robert@gmail.com>=EB=8B=98=EC=9D=B4= =EC=9E=91=EC=84=B1:
On Fri, Mar 29, 2024 at 3:41=E2=80=AFAM =ED=95=98=EB=8A=98=EC=95=84=EB= =B6=80=EC=A7=80 <daddyofsky@gmail.com> wrote:
>
> Hello.
>
> I created a wiki for __callStatic related issues.
> Please see:
> https://wiki.php.net/rfc/complete_callstatc_ma= gic
>
> I look forward to your interest and advice.
>
> Best Regards.
> Daddyofsky

Hey there,

Some general feedback:

The RFC is a bit hard for me to follow, for example:

> However, the IDE cannot find active method, and the Go to Definition f= eature cannot be used.

This sounds like a bug or feature request with your IDE, not a problem with= PHP.

> This code is very clear, aside from the fact that the method is not st= atic.

Clear to whom? As a developer this looks downright confusing. I can't even guess what the actual behavior is. If you call a non-static
method statically, its currently an error. Why would this not be an
error?

> The IDE recognizes active methods well and the Go to definition featur= e also works properly.

What is stopping the IDE to taking you to the __callStatic method?
That would be the correct behavior IMHO, not the implementation for
instance methods.

> Even if there are only a few core methods, it cannot be made into a si= ngle file.

There is nothing stopping you from putting multiple classes in a file.

> As can be seen in the above examples, the code becomes clearer, and na= vigation through the IDE works much better.

I completely disagree. It mixes concerns and makes spaghetti code into
incomprehensible code. Also, maybe you should take up IDE navigation
with your IDE?

> Instead of throwing an error when a non-static public method is called= statically, the _ _callStatic method should be invoked.

I completely agree with this, btw. Your examples could use some work
and shows all the reasons why it shouldn't call __callStatic(). A real<= br> life example, that has nothing to do with a specific framework:

When generating proxies for existing types, you often need to share
some state between the proxies. To do that, you put static
methods/properties on the proxy class and hope to the PHP Gods that
nobody will ever accidentally name something in their concrete class
with the name you chose for things. To help with that, you create some
kind of insane prefix. If __callStatic() were called ALWAYS in a
static context, even if a non-static method exists, then collisions
would literally be impossible. But at that point, why can't I just
write:

class Test {
=C2=A0 public static function test(): string { return "hello world&quo= t;; }
=C2=A0 public function test(): int { return random_int(); }
}

??? I feel like this is your real RFC and should be allowed if we're allowed to __callStatic() to instance methods. I don't think it makes sense to have one without the other, and then what you want with
__callStatic() comes naturally, instead of this weird and confusing
RFC.


Robert Landers
Software Engineer
Utrecht NL

Hello.
=C2=A0<= br>I'm not very familiar with documentation. It would be helpful if you= could suggest how to fix the problematic parts.

Using the example o= f the IDE meant to illustrate that it should be intuitive enough for the ID= E to find it directly.

Even currently, `__callStatic` is called in c= ases of non-static methods that are not public methods. `__callStatic` alre= ady acts as a rule-breaker. It seems like there's a desire for the magi= c method to be named as such without actually causing much magic. The curre= nt `__callStatic` is like a magician who can use high-level magic to hit ta= rgets behind doors or invisible targets but can't use basic magic to hi= t a visible door.

While it's good that the PHP kindly notifies e= rrors, I think it would also be beneficial to provide users with options to= do other things, specifically when they intentionally use `__callStatic`. = That's the core point of this proposal.

If there are better exa= mples or ways to explain, I would appreciate learning about them.

Daddyofsky
--000000000000e27d7c0614d5884c--