On Thu, Nov 23, 2023 at 7:00 AM Stephen Reay <php-li...@koalephant.com> wrote:
>
>
>
> > On 21 Nov 2023, at 06:48, Mike Schinkel <m...@newclarity.net> wrote:
> >
> > Wow.
> >
>
> Hi,
>
> (This is not a direct reply to Mike, his just seems to be less shouty than
> other recent emails)
>
> I'm not *particularly* bothered by the results of this specific RFC either
> way - a *similar enough* result is already possible by grouping static
> methods in an abstract class, but I'm disappointed to see yet again that
> there's this implied notion that working with PHP in 2023 means "well surely
> you must be using composer", which leads to "but composer..." somehow being
> an accepted argument when it comes to missing/incomplete builtin
> functionality.
>
> Despite the way some treat it, this isn't the composer internals list, nor is
> composer a required or even bundled part of PHP.
>
>
> Does that mean you shouldn't use composer? No, if it works for your project,
> that's great.
>
> Does that mean gaps in the php language/standard library should be
> automatically ignored/glossed over because composer may provide a
> work-around? Also, no.
>
>
> PHP has for a very long time stood out amongst other web-focused languages
> for having a very rich standard library out of the box ('batteries included',
> I think the cool kids would say now).
>
> Let's please not take PHP in the direction of "modern JavaScript" where
> language deficiencies mean that an entire alphabet of constantly changing
> third-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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
