look you couldn't pay me any amount of money to work on Wordpress, but not cargo culting PSR like a bunch of others isn't the red flag you make it out to be.
I was dubious when they declared that projects indent method is somehow a barrier to "interoperability".
When they made a logging system based on strings because one existing implementation was written by a guy who apparently doesn't understand syslog levels, I gave up any expectation that they'd produce anything of value.
It's design by committee with the added bullshit of wanting to emulate Java.
PSR has been the single most important advance in the ecosystem. We now have a single, unified code style among all modern projects; a universally supported logging library that virtually all applications use; a universally supported DI container that is implemented by all frameworks; common HTTP request and response types, used or supported by all major frameworks and HTTP clients alike; sadly, two cache standards, albite with a little different targets, but at least most packages support either.
For a concrete example; I can take a PSR request received from the server SAPI, send that to an upstream server via a PSR client retrieved from a PSR container, hand it a PSR cache instance to store the PSR response in, then return that response to the client. This whole chunk of code can be copy-pasted from Laravel to Symfony, and the container will handle injecting the correct local implementation. That doesn’t sound too impressive to a Java developer, but it just wasn’t there in PHP before PSR. Anyone dismissing all that hasn’t really worked on libraries and frameworks before that was a thing.
These packages have made it feasible to create framework-agnostic libraries, easy even, if you’ve got a bit of PHP experience. There’s a reason why the packagist/composer ecosystem is so good, and that’s shared primitives.
If someone just denies all that and bets on their own, badly documented, incompatible solutions just for the sake of it; that absolutely is a red flag, and I’m not going to touch that with a ten foot pole.
> We now have a single, unified code style among all modern projects
Yes I mentioned that, and it's kind of ridiculous how much importance people put on it.
If you can't use another library because they use tabs rather than spaces, that should be a red flag.
> a universally supported logging library
PSRs don't define a logging library. They define a logging interface, and it's based around strings rather than the literal industry standard of SYSLOG levels, because a single implementation that pre-dated the PSR, uses integers but not SYSLOG.
If you think it's a good idea to use a logging library written by someone who doesn't understand syslog, or to use an interface written by people who think it's better to make up shit to accomodate said people who don't understand syslog, be my guest.
But as someone recently said:
> I’m not going to touch that with a ten foot pole
> If you can't use another library because they use tabs rather than spaces, that should be a red flag.
Now that’s just disingenuous. Coding style differences cause issues in collaboration and man-years of bike shedding and have wasted an incredible amount of time in the open source community. Settling on a single standard and be done with it seems very much sensible to me. It’s not about being unable to use a library, but having trouble (or causing it) when contributing.
> PSRs don't define a logging library. They define a logging interface, […]
You’re right of course, although I’m sure you knew exactly what I meant. We’re dealing with a specification that has several implementations, and that doesn’t finish its usefulness at all. I don’t know where your grief around syslog comes from, and I honestly don’t care; Monolog is both flexible and extensible enough to cater to 99% of all use cases or can be adapted to, out of the box. How someone could care that much how the log levels are implemented internally is beyond me; in the meantime, I have built a bunch of applications chugging out logs just fine.
I’ve seen the benefits of PSR firsthand for many years now, but I guess I’m not going to convince you, so I think we can leave it at that.
> Coding style differences cause issues in collaboration and man-years of bike shedding
Solved by each project having its own defined coding style. Every "member" project of PHP-FIG had a defined coding style prior to any PSR telling them how to write code.
There is zero need for this to be enforced across projects.
> I don’t know where your grief around syslog comes from, and I honestly don’t care
You're gesticulating about how important it is to follow "standards", but the moment someone points out how PHP-FIG ignored an established standard that's already used in dozens of languages - including in PHP, it's "I don't care".
You're more concerned with defending your cargo-cult allegiance to a group than understanding criticisms of their work.
I was dubious when they declared that projects indent method is somehow a barrier to "interoperability".
When they made a logging system based on strings because one existing implementation was written by a guy who apparently doesn't understand syslog levels, I gave up any expectation that they'd produce anything of value.
It's design by committee with the added bullshit of wanting to emulate Java.