Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124404
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\))
Subject: Re: [PHP-DEV] [RFC] Static class
In-Reply-To: <132b86de-f571-4611-8b9b-35ae107901f0@scriptfusion.com>
Date: Fri, 12 Jul 2024 03:10:47 -0400
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <B723453F-A8C7-49DA-8413-2CF292F743ED@newclarity.net>
References: <eb3f59cc-3ed8-461a-a3a4-f6ba10ed31e1@scriptfusion.com>
 <ef0c3617-6757-45a1-a485-3f7c197fd599@app.fastmail.com>
 <4596aa73-cfd4-2292-7191-2839a5bab695@php.net>
 <132b86de-f571-4611-8b9b-35ae107901f0@scriptfusion.com>
To: Bilge <bilge@scriptfusion.com>
From: mike@newclarity.net (Mike Schinkel)

> On Jul 11, 2024, at 8:14 PM, Bilge <bilge@scriptfusion.com> wrote:
>=20
> On 25/06/2024 16:17, Derick Rethans wrote:
>> we shouldn't be encouraging static classes as=20
>> a bag of static functions, that ought to be just namespaced =
functions.
>>=20
>> cheers,
>> Derick
>>=20
> Can someone clue me in as to why grouping related functions in a file =
with nothing but a namespace is strictly better than those same related =
functions grouped as members of a class? It doesn't have to be Larry or =
Derick, because even though they have expressed this view, I am aware =
they are not the only ones whom hold it. Anyone who can shed some light =
on this perspective is welcome to comment.

I cannot answer your question as posed but I can give you a =
counter-reason, one supporting the use of static classes as a bag of =
static functions, at least with the feature set of PHP 8.4 and prior. =20=


If a developer needs to hide global state =E2=80=94 and there are valid =
reasons for maintaining global state using static classes along with a =
related set of static functions. Minimally, when using streams with =
include*()/require*() e.g. include("myprotocol://${handle}") namespaces =
simply do not have the necessary visibility scoping features and thus =
are not an option.

I am currently working on a PoC for packages in userland that uses =
static classes exactly in this way. I will hopefully be able to share =
working code for that soon.

-Mike

P.S. None of include*()/require*() accept a stream context AFAICT. If =
they did a developer could pass in a dependency object as a context, but =
currently (again, AFAICT) there is no way to associate a dependency =
object with an include*()/require*() call. The only approach I have been =
able to identify to allow access to retrieve and update a dependency =
object is to use a key into a array in a private static property with =
public static get/set methods. =20

If context were added to include*()/require*() and/or visibility scoping =
where added to symbols within namespaces then this use-case would no =
longer be an argument for static classes. But unless and until then, =
static classes are the only way to go. #fwiw=