Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123621
Precedence: bulk
MIME-Version: 1.0
References: <0cf69a14-f1b5-4077-9d91-d7b579485eec@scriptfusion.com>
 <936e1aa3-48cc-4552-9f68-676ebcdeb596@rwec.co.uk> <1fc2f2d0-718f-45ec-8968-b66a1bde686e@scriptfusion.com>
 <c2472dca-a297-4f14-bf53-b0ab9a67d3c7@rwec.co.uk> <b6d67db7-6689-4a1c-ad62-32cc96a01392@scriptfusion.com>
In-Reply-To: <b6d67db7-6689-4a1c-ad62-32cc96a01392@scriptfusion.com>
Date: Sat, 15 Jun 2024 20:39:20 +0300
Message-ID: <CAPyeZ4NW3eoaaXonM8bTHmji0a=CpWx7m8B5h_X44-eFDfOQbw@mail.gmail.com>
Subject: Re: [PHP-DEV] Static class
To: Bilge <bilge@scriptfusion.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000f21b1e061af13601"
From: udaltsov.valentin@gmail.com (Valentin Udaltsov)

--000000000000f21b1e061af13601
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, 15 June, 2024=E2=80=AFat 19:21, Bilge <bilge@scriptfusion.com> wrot=
e:

> On 15/06/2024 16:58, Rowan Tommins [IMSoP] wrote:
> > Common arguments against:
> >
> > - Static properties are a form of global state, and that's something
> > widely advised against
>
> Correct, but a static class does not need to have any state. Indeed, I
> cannot think of an instance where I (personally) have needed state in a
> static class. If this ever becomes a point of contention (though I doubt
> it would), we could even consider prohibiting state in static classes,
> locking it down completely to just methods. A draconian option, but an
> option nonetheless.
>
> > - Static classes without any properties would be the same as putting
> > functions and constants in a namespace, which we can already do
>
> You already provided a counter-point to this; we can't autoload
> functions. Besides, there may be good reason (organizationally) to group
> sets of static functionality together (in a class) rather than having
> them as free-standing functions only so grouped in a file (which does
> not necessarily imply the same degree of cohesion).
>
> >> rather than fall back on the opinions of many who are mostly absent
> >> among those polled nine years ago, I'd rather get a sense of the
> >> current sentiment of those present today.
> >
> > This line of thinking always makes me uneasy. It lends undue weight to
> > *who* made decisions, and not enough to *why*.
>
> Meaning no disrespect to anyone whom was participating nine years ago (I
> have nothing but respect for those whom came before), I really don't
> care _who_ fielded opinions or decisions, my point was simple and
> singular: that even if an opinion was valid back then, if nobody were to
> uphold it today, it wouldn't carry any weight now. I think enough time
> has passed that gauging the sentiment of today is valid and worthwhile,
> especially if it has shifted (and we cannot know without asking).
>
> Cheers,
> Bilge
>

Hi!

> Static classes without any properties would be the same as putting
> functions and constants in a namespace, which we can already do

In addition to the absence of autoloading, this is also not correct because
PHP does not have internal/private functions.
Very often I use functions for really simple things like `array_flatten`
(and register them via composer.json.autoload.files). But when the function
requires decomposition to smaller ones, I switch to a static class with one
public and some private static methods.

I tend to support this idea, because it makes intent more expressive and
allows to get rid of `private function __construct() {}` visual debt.
I also agree that static implies final. This could be later changed without
breaking BC.

Good luck, Bilge!
--=20
Valentin Udaltsov

--000000000000f21b1e061af13601
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Sat, 15 June, 2024=E2=80=AFat 19:21, B=
ilge &lt;<a href=3D"mailto:bilge@scriptfusion.com">bilge@scriptfusion.com</=
a>&gt; wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">On 15/06/2024 16:58, Rowan Tommins [IMSoP] wrote:<=
br>
&gt; Common arguments against:<br>
&gt;<br>
&gt; - Static properties are a form of global state, and that&#39;s somethi=
ng <br>
&gt; widely advised against<br>
<br>
Correct, but a static class does not need to have any state. Indeed, I <br>
cannot think of an instance where I (personally) have needed state in a <br=
>
static class. If this ever becomes a point of contention (though I doubt <b=
r>
it would), we could even consider prohibiting state in static classes, <br>
locking it down completely to just methods. A draconian option, but an <br>
option nonetheless.<br>
<br>
&gt; - Static classes without any properties would be the same as putting <=
br>
&gt; functions and constants in a namespace, which we can already do<br>
<br>
You already provided a counter-point to this; we can&#39;t autoload <br>
functions. Besides, there may be good reason (organizationally) to group <b=
r>
sets of static functionality together (in a class) rather than having <br>
them as free-standing functions only so grouped in a file (which does <br>
not necessarily imply the same degree of cohesion).<br>
<br>
&gt;&gt; rather than fall back on the opinions of many who are mostly absen=
t <br>
&gt;&gt; among those polled nine years ago, I&#39;d rather get a sense of t=
he <br>
&gt;&gt; current sentiment of those present today.<br>
&gt;<br>
&gt; This line of thinking always makes me uneasy. It lends undue weight to=
 <br>
&gt; *who* made decisions, and not enough to *why*.<br>
<br>
Meaning no disrespect to anyone whom was participating nine years ago (I <b=
r>
have nothing but respect for those whom came before), I really don&#39;t <b=
r>
care _who_ fielded opinions or decisions, my point was simple and <br>
singular: that even if an opinion was valid back then, if nobody were to <b=
r>
uphold it today, it wouldn&#39;t carry any weight now. I think enough time =
<br>
has passed that gauging the sentiment of today is valid and worthwhile, <br=
>
especially if it has shifted (and we cannot know without asking).<br>
<br>
Cheers,<br>
Bilge<br>
</blockquote></div><div><br></div><div>Hi!</div><div><br></div><div>&gt; St=
atic classes without any properties would be the same as putting<br>&gt; fu=
nctions and constants in a namespace, which we can already do<br><br>In add=
ition to the absence of autoloading, this is also not correct because PHP d=
oes not have internal/private functions.</div><div>Very often I use functio=
ns for really simple things like `array_flatten` (and register them via com=
poser.json.autoload.files). But when the function requires decomposition to=
 smaller ones, I switch to a static class with one public and some private =
static methods.</div><div><br></div><div>I tend to support this idea, becau=
se it makes intent more expressive and allows to get rid of `private functi=
on __construct() {}` visual debt.</div><div>I also agree that static implie=
s final. This could be later changed without breaking BC.</div><div><br></d=
iv><div>Good luck, Bilge!</div><span class=3D"gmail_signature_prefix">-- </=
span><br><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr">Valent=
in Udaltsov<br></div></div></div>

--000000000000f21b1e061af13601--