Skip to content
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

Explicit PSR-11 support #1054

Merged
merged 7 commits into from Aug 30, 2017

Conversation

Projects
None yet
2 participants
@everzet
Copy link
Member

commented Jun 30, 2017

No description provided.

@Taluu

This comment has been minimized.

Copy link
Contributor

commented Jun 30, 2017

Hum, I think like #1014, there are several bc breaks. See the comments @stof made (It was on thing implementing / extending the interop interfaces, now implementing the psr's ones ; one should expect that these classes / exceptions accept the typehinting from the interop, but they don't).

Only the typehints should be changed to be compatible with psr 11.

Unless I'm reading and understanding it wrongly...

@everzet

This comment has been minimized.

Copy link
Member Author

commented Aug 30, 2017

@Taluu @stof container-interop was updated with a minor to migrate to PSR-11. In 1.2 they basically extend all the base PSR-11 interfaces.

There's also no public API change, so the upgrade from Interop 1.1 to Interop 1.2 (which extends PSR-11) is non-breaking. This all means that for people depending on Interop container interfaces the change should be transparent. Unless they are locking particular minor version of Interop in their composer.json, which there's no reason to.

@everzet everzet force-pushed the feature/psr-11-support branch from 1ad84d5 to 39c4ab5 Aug 30, 2017

@everzet

This comment has been minimized.

Copy link
Member Author

commented Aug 30, 2017

@Taluu @stof I specified explicit conflict with container-interop prior to 1.2 in composer.json, which would explicitly force Composer to update container-interop to 1.2. Unless users locked their container-interop version, in which case they would be forced to unlock it.

everzet added some commits Jun 30, 2017

@everzet everzet force-pushed the feature/psr-11-support branch from 39c4ab5 to 3b52e20 Aug 30, 2017

@Taluu

This comment has been minimized.

Copy link
Contributor

commented Aug 30, 2017

The mentionned BC break is for example on your exceptions. Before the PSR-11 implementation, even though it is using interop > = 1.2, one would for example try to catch a Interop\NotFoundException, while now only a Psr\Container\NotFoundException (the names are redacted, I'm too lazy to llok for the real names), which would now be incorrect.

@stof's point was that the thing in behat that extends / implements something from interop AND/OR PSR11 should still accept / implement the interop interfaces, so that nothing breaks.

don't get me wrong though, I do not really care for BC Breaks, such a minor one is okay IMO.

@everzet

This comment has been minimized.

Copy link
Member Author

commented Aug 30, 2017

@Taluu you and @stof are right in regards to exceptions and more generally implement. Switched all internal container classes back to extend from Interop-Container rather than PSR11.

@everzet everzet changed the title PSR-11 support Explicit PSR-11 support Aug 30, 2017

@everzet everzet merged commit c48c639 into master Aug 30, 2017

3 checks passed

Scrutinizer No new issues
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@everzet everzet deleted the feature/psr-11-support branch Aug 30, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.