Skip to content

[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

Merged

Conversation

stefanotorresi
Copy link
Contributor

also reword the paragraph to be more conservative and less biased

ref: ML thread

also reword the paragraph to be more conservative and less biased
- [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)
Copy link
Member

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

Copy link
Contributor Author

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.

@mnapoli
Copy link
Member

mnapoli commented Feb 9, 2017

👎 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".

@stefanotorresi
Copy link
Contributor Author

stefanotorresi commented Feb 9, 2017

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

@weierophinney
Copy link
Contributor

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

@stefanotorresi
Copy link
Contributor Author

@mnapoli @weierophinney I reinstated the previous categories.
I now just added League Container and Zend ServiceManager to implementors, stripped out descriptions (as it didn't make much sense to only describe some packages and leave others without comment), and reworded intro and outro paragraphs.

@mnapoli
Copy link
Member

mnapoli commented Feb 9, 2017

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

@mnapoli
Copy link
Member

mnapoli commented Feb 15, 2017

👍

Approved with PullApprove

@afolson afolson merged commit 273dd25 into php-fig:master Feb 16, 2017
@stefanotorresi stefanotorresi deleted the psr-11/simplify-implementations-list branch February 16, 2017 21:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants