Re: RFC Proposal - static modifier for classes

> 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 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