I hadn't actually considered adoption at any scale - I just thought the overall approach was cool, and the code might be useful to folks looking for this exact thing. The PSRs were lurking in the back of my thoughts during the cleanup for publication, though. Argh. They're a bit outside my normal coding style.
Re: libsodium, there will be optional support for it at some point precisely because it's going into the core, but I try to do all my components like this with no required dependencies. I'm not even entirely satisfied with Lockbox requiring the openssl extension, but that's far preferable to yet another homespun AES implementation.
I can basically understand if you said "you need to support composer (be on packagist).
But seriously? The only psr that would apply is autoloading (which it does use) and code style.
Given the amount of random fucking shit people include via language level package managers, if your concern is "oh the braces are in the wrong spot" I think you need to re-evaluate your priorities
The single biggest stereotype held against the PHP community is they are a bunch of shitty amateur programmers whose programming ability barely extends beyond copy-pasting stackoverflow. Very few of the language-centric criticisms are valid these days.
Granted a lot of these criticisms are often levied by trendy kids reinventing the wheel with Ruby, MongoDB, NodeJS, Go, Docker, etc (2008-2017 roughly), but unfortunately they tend the tone for tech as a whole, so PHP still has this very negative reputation even though we tend to get more shit done, make more money, and spend less time learning the latest new fad.
Adhering to PSRs goes a long way to combat that stereotype by having a consistent look and feel to open source packages. Attention to detail leads to code quality. Initiatives like phptherightway really help out the community by putting people on the right track from day #1.
I agree there's a ton of utter shit out there on packagist and I avoid 99.9% of it like the plague for this very reason.
I agree. But the PSR's approach things the wrong way IMO.
The style related PSR's should be exactly two rules:
1. Choose an existing/define a formatting style for the project.
2. Ensure the style is enforced, ideally using a code style formatting tool like phpcs, your IDE, etc
Thats it. Claiming that a project isnt up to scratch because it doesnt conform to an abritrary style that was created literally by what was most common in the member projects at the time, is frankly ridiculous.
Their subsequent decisions show a frankly laughable approach to development. Psr-whatever that defines a logging interface. Every man and his dog uses integer levels, usually the syslog 0-7 range.
This makes it extremely simple to ignore/filter out logs above a given priority.
What do they decide to do? Fuck it, make the defined log levels strings. Why? Because an existing project happened to already use integers that didnt adhere to syslog, and they didn't want to deal with it.
So fuck it, lets have a shittier, less sensible "standard" just so fucking monolog can keep using 400 to mean error or whatver it is.
Readability is good, standardisation is good. The latter should be a project level decision, and honestly ive never seen anyone who's picked a standard - any standard - that meant readability was a problem.
Re: libsodium, there will be optional support for it at some point precisely because it's going into the core, but I try to do all my components like this with no required dependencies. I'm not even entirely satisfied with Lockbox requiring the openssl extension, but that's far preferable to yet another homespun AES implementation.