On Sat, 15 June, 2024 at 19:21, Bilge <[email protected]> wrote:
> 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!
--
Valentin Udaltsov