Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122801
Date: Fri, 29 Mar 2024 09:43:28 +0000
To: =?utf-8?B?7ZWY64qY7JWE67aA7KeA?= <daddyofsky@gmail.com>
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Invoke __callStatic when non-static public methods are called statically
Message-ID: <HQP-nIjJQFNP4ZkC5eZE_q8g3GqO9MROfzMev_jysNQTr_EezCfeiHJT6pmwmpSu0uCeNCivUD5ot3uFxwS9J1XCXoKx5P96rDwuwdb6UBo=@chstudio.fr>
In-Reply-To: <CAKkgovQcibHLQibK44wtcEbi-oKVQ5ifCiZPgN8SR2RCg5yMGQ@mail.gmail.com>
References: <CAKkgovQcibHLQibK44wtcEbi-oKVQ5ifCiZPgN8SR2RCg5yMGQ@mail.gmail.com>
Feedback-ID: 41282912:user:proton
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------4f06def30944c9099cf5fb7b7ce724f3dccae01ede032970d83b8e82b2f4dacb"; charset=utf-8
From: s.hulard@chstudio.fr (=?utf-8?Q?St=C3=A9phane_Hulard?=)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------4f06def30944c9099cf5fb7b7ce724f3dccae01ede032970d83b8e82b2f4dacb
Content-Type: multipart/mixed;boundary=---------------------15a7e482d53382868421eb0a350dba4b

-----------------------15a7e482d53382868421eb0a350dba4b
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;charset=utf-8

Le vendredi 29 mars 2024 =C3=A0 03:39, =ED=95=98=EB=8A=98=EC=95=84=EB=B6=80=
=EC=A7=80 <daddyofsky@gmail.com> a =C3=A9crit=C2=A0:

> 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

Hello !

I took a look at your proposal and I think about important issues if we go=
 this way.

A static method mustn't used the `$this` variable because it simply doesn'=
t exists in the static context. The examples you're adding in the RFC are =
fine but they always rely to a specific `__callStatic` implementation that=
 will use a new instance of the object to forward the call.

There are multiple cases where it'll be complicated to use it this way. Tw=
o of them I have in mind:

- What if the object needs important parameters in its constructor that ar=
en't available in the static context ? Or those parameters need to be init=
ialized outside of the `__callStatic` method?
- What if the underlying non static method we are trying to invoke is usin=
g the `$this` variable?

In those two examples, I would prefer having a fatal error that explains t=
hat I'm not doing the call correctly (calling a non static method in the s=
tatic context) to ensure it'll be easy to understand and fix.

The use cases you are describing here have been fixed in the user space by=
 the Laravel team. It's a very specific way of working that's mostly speci=
fic to Laravel.

For sure it makes the code harder to read since you can't jump to a real m=
ethod easily (because most of the methods are magic ones and are forwarded=
 to underlying objects). I don't tell it's wrong but I'm not sure it's rel=
evant to make the whole language simplify this process.

If there is a way to work correctly with those static vs non static calls =
and capture relevant errors to expose them to users, that's fine.

However, I think this is an important behavior change because it'll allow =
a new way to work with method that were forbidden before.

Regards
St=C3=A9phane
-----------------------15a7e482d53382868421eb0a350dba4b--

--------4f06def30944c9099cf5fb7b7ce724f3dccae01ede032970d83b8e82b2f4dacb
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wnUEARYKACcFgmYGjS8JkFAFamSXyqbjFiEEAbZnit5cX2dsfkYRUAVqZJfK
puMAAO/OAP9NWqADeWG5od0I0P3hxbUOnKYsI0IyEFbnPCig6YHrDAD9Ee2H
SZb20/WKMhEiGwQe08J4t5K5ejeU1EBxR3yGjg4=
=Eo2z
-----END PGP SIGNATURE-----


--------4f06def30944c9099cf5fb7b7ce724f3dccae01ede032970d83b8e82b2f4dacb--