> 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
