-
Notifications
You must be signed in to change notification settings - Fork 2.8k
[PSR-11] simplify implementors and consumers list #883
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[PSR-11] simplify implementors and consumers list #883
Conversation
also reword the paragraph to be more conservative and less biased
proposed/container-meta.md
Outdated
- [Prophiler](https://github.com/fabfuel/prophiler) | ||
- [Silly](https://github.com/mnapoli/silly) | ||
- [Slim](https://github.com/slimphp/Slim) | ||
- [Splash](http://mouf-php.com/packages/mouf/mvc.splash-common/version/8.0-dev/README.md) | ||
- [XStatic](https://github.com/jeremeamia/xstatic) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Symfony can now be added here too!
symfony/symfony#21265
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Jean85 this list shows implementors of the Interop\Container
vendor to show pre-PSR adoption, while Symfony is actually ahead of time by implementing directly Psr\Container
, so I don't think it should be included.
👎 the distinction between projects implementing and consuming container-interop is very important: the "consuming" part shows the need for the interface. The "implementing" part shows the "offer". |
@mnapoli I beg to disagree. The distinction is not that clear for some projects (e.g. large frameworks have both implementations and consumers), and you cannot possibly make any noteworthy assessment of how many consumers are out there, because most of them are userland applications, not libraries (not to mention that presenting just two middlewares on a separate section is honestly useless). More to the point, since the research is not comprehensive or in any way thorough, nor it can be kept current, it is basically irrelevant. It's just sample data, I find that presenting it like a statistic can be regarded as highly biased. At the end of the day, I'd rather convey a more relaxed message "hey, by the way, here are a bunch of packages using this interface already" rather than a prententious and needy "Look ma, I have x implementors, y middlewares and z consumers, and look at all the shiny download numbers! We must be so important!", but maybe that's just how I read it. |
I tend to agree that removing the downloads bit makes sense. That said, I agree with separating the projects by implementors and consumers, as I think that demonstrates the different development audiences (those that provide containers (implement the interfaces), and those that consume them (typehint against them)). They represent two separate use cases. It's similar to PSR-7; those implementing are usually far fewer, but relevance is more interesting in terms of those who consume. (I'd also likely move the "middleware" section into the "consumers" section.) |
@mnapoli @weierophinney I reinstated the previous categories. |
@stefanotorresi thanks for taking the time to explain it, it makes more sense now, I understand what you mean about the download numbers. The new diff looks good to me! |
also reword the paragraph to be more conservative and less biased
ref: ML thread