Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121769
MIME-Version: 1.0
References: <79d675e3-95b4-40bb-baf4-3e1c998f5390@online-presence.ca>
 <CAPTD5yH9Wk=ADvCRf4K3SVNm+hfyarHr8_4hQAMbt-zDH4zxkA@mail.gmail.com>
 <CAGBsUreqkyoohwL0B7o8WFQLLcekMryDmDRQ1ksoF2FZCt9WOA@mail.gmail.com>
 <34979AED-893F-45DD-B641-A9F4F39B2928@newclarity.net> <2D505086-6AD9-4596-A515-85B50F5D12C5@koalephant.com>
In-Reply-To: <2D505086-6AD9-4596-A515-85B50F5D12C5@koalephant.com>
Date: Thu, 23 Nov 2023 08:43:21 +0100
Message-ID: <CAPzBOBMPgSvnnsMZEELT7u+kma7OsK6rRvwddTzmM+PjC=5emg@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] RFC Proposal - static modifier for classes
From: landers.robert@gmail.com (Robert Landers)

On Thu, Nov 23, 2023 at 7:00=E2=80=AFAM Stephen Reay <php-lists@koalephant.=
com> wrote:
>
>
>
> > On 21 Nov 2023, at 06:48, Mike Schinkel <mike@newclarity.net> wrote:
> >
> > Wow.
> >
>
> Hi,
>
> (This is not a direct reply to Mike, his just seems to be less shouty tha=
n other recent emails)
>
> I'm not *particularly* bothered by the results of this specific RFC eithe=
r way - a *similar enough* result is already possible by grouping static me=
thods in an abstract class, but I'm disappointed to see yet again that ther=
e's this implied notion that working with PHP in 2023 means "well surely yo=
u must be using composer", which leads to "but composer..."  somehow being =
an accepted argument when it comes to missing/incomplete builtin functional=
ity.
>
> Despite the way some treat it, this isn't the composer internals list, no=
r is composer a required or even bundled part of PHP.
>
>
> Does that mean you shouldn't use composer? No, if it works for your proje=
ct, that's great.
>
> Does that mean gaps in the php language/standard library should be automa=
tically ignored/glossed over because composer may provide a work-around? Al=
so, no.
>
>
> PHP has for a very long time stood out amongst other web-focused language=
s for having a very rich standard library out of the box ('batteries includ=
ed', I think the cool kids would say now).
>
> Let's please not take PHP in the direction of "modern JavaScript" where l=
anguage deficiencies mean that an entire alphabet of constantly changing th=
ird-party tooling is required to do anything but the simplest tasks.
>
>
> Cheers
>
>
> Stephen
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

Hello,

I'd venture to say that static classes have some unique benefits over
plain functions. One, you can encapsulate state using private static
variables. That simply isn't possible with regular functions (unless
you use static variables in the functions themselves, which isn't
quite the same thing). Two, you still have inheritance that you can
use with static functions. You can't really have inheritance with
regular functions unless you are strictly passing around closures.
Third, static functions can also use traits (in theory) to allow for
code reuse. Fouthly, not everyone is writing s Symfony/Laravel
application that needs highly testable code and might just be throwing
a prototype together -- static classes could hold static configuration
for the app.

In something like C#, static classes are used as a way to extend parts
of the language.

One thing for Lanre: please do not remove the requirement to
explicitly mark a method as static with this. As someone who has read
very long readonly classes, when you make a change, you usually don't
find out it is readonly until you make that change. This is because
the "readonly" is at, and only at, the very top of the class. Now, if
you need to make the class non-readonly, but want to keep all the old
variables readonly, you have to make dozens of changes. Please, for
the life of sane refactoring, don't make "static class" a shortcut for
not being explicit, just make it so that things MUST be declared
static. Long classes are (unfortunately) a thing, and it makes
everything more obvious as to what is going on. Further, removing
static from the class, the class should still function, IMHO.

Robert Landers
Software Engineer
Utrecht NL