Skip to content
This repository has been archived by the owner on Feb 6, 2020. It is now read-only.

Replace container-interop with PSR-11 container interface #187

Merged
merged 8 commits into from
Feb 11, 2018
Merged

Replace container-interop with PSR-11 container interface #187

merged 8 commits into from
Feb 11, 2018

Conversation

michaelmoussa
Copy link

This PR replaces use of the container-interop package with the PSR-11 container interface. This is obviously a BC break and would need to be released in ServiceManager 4.0 along with a migration guide.

Since zend-eventmanager comes into play when ProxyManager is used for lazy instantiation of services (via its own dependency on zend-code, which in turn depends on zend-eventmanager), I'll be submitting an equivalent PR on that repository shortly and will link it here when it's up.

Copy link
Member

@weierophinney weierophinney left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great, and I'm ready to merge it to develop for release in 4.0.0. I need a couple of things, though:

  • A rebase against current develop, as we've pulled in a ton of changes recently.
  • A migration document, detailing how developers will need to update their code that implements any of the various factory interfaces to work with the new version. This essentially becomes "find 'Interop\Container' and replace with 'Psr\Container' in your codebase".

Once those are in place, I'll merge to develop.

Thanks!

@michaelmoussa
Copy link
Author

Thanks @weierophinney - will do. Do you happen to have a link to a sample migration document for any similar change made in the past that I might be able to use as a template?

@weierophinney
Copy link
Member

@michaelmoussa
Copy link
Author

@weierophinney Rebase is complete. All the remains is the migration guide. Do you prefer a short section for v4 changes in the existing migration guide, or do you want to keep each major version's migration guide separate?

@weierophinney
Copy link
Member

All the remains is the migration guide. Do you prefer a short section for v4 changes in the existing migration guide, or do you want to keep each major version's migration guide separate?

Do it as a separate document. I will likely be creating a sub-tree for the v3 docs once we're ready to move to v4, so having them separate will make that easier (no need to split out the information to a new file).

@michaelmoussa
Copy link
Author

@weierophinney Hmm, separate document but not new file..? Do you mean clear out the existing migration.md file and start putting v4 stuff in it?

@weierophinney
Copy link
Member

New file. Call it something like migration-v4.md or similar.

@michaelmoussa
Copy link
Author

@weierophinney Initial draft added. I didn't add it to the mkdocs.yml, so up to you how you want to link it up.

I have a similar PR open for zendframework/zend-eventmanager. It's been a while since I opened these, so I'm not sure if the EventManager one still needs to be merged and released prior to the ServiceManager one. In any event (heh), I'll be updating the EventManager one as well sometime this week.

` as ContainerException` in the find-and-replace, and any existing use of `ContainerException`
will continue to work.

**NOTE:** If you use fully-qualified class names in your typehints, rather than
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For this type of note we should use a blockquote:

> ### Note
>
> If you use fully-qualified class names in your typehints, rather than
> …

` as ContainerException` in the find-and-replace, and any existing use of `ContainerException`
will continue to work.

### Note
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A blockquote needs > in front of every line.

Example "Tip: Serve via Composer": https://docs.zendframework.com/zend-expressive/getting-started/standalone/#5-start-a-web-server

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@froschdesign fixed - thanks! Sorry I missed that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@michaelmoussa

Sorry I missed that.

No problem. Thanks! 👍

@Ocramius Ocramius added this to the 4.0.0 milestone Jan 9, 2018
@Ocramius
Copy link
Member

Ocramius commented Jan 9, 2018

Overall, this looks good, but develop is currently targeting 3.4.0, so we need to wait for that release before moving on with this patch.

@michalbundyra
Copy link
Member

@Ocramius as I can see develop is now targeting 4.0-dev, is there any chance to merge this PR and than we can move forward with this package? Thanks !

@Ocramius
Copy link
Member

Could we rebase to see if all is good?

@michalbundyra
Copy link
Member

@michaelmoussa could you rebase it please? If you don't have time to do that, I can do it if you give me permission to push into your branch 😄


[`container-interop/container-interop`](https://github.com/container-interop/container-interop)
was officially deprecated in favor of [PSR-11](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-11-container.md)
on February 13, 2017. As such, all uses of the `Interop\Container\*` interfaces
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There was more than one interface? Why there is *?

> advantage of `use` statements, you will need to run additional find-and-replace
> commands to update those class paths within your code. The exact finds and
> replaces to run for those scenarios are not covered in this migration guide, as
> they can vary greatly and are not a generally recommended practice.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The migration process is very basic, but I think it would be nice to have migration tool. I think it could be done later on, so I'd like to leave just a note for that. Unless you have another idea?

I think delivering migration tools will help to migrate quicker to newer version.

class ServiceNotCreatedException extends SplRuntimeException implements
ContainerException,
ExceptionInterface
class ServiceNotCreatedException extends SplRuntimeException implements ContainerExceptionInterface
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should implement here just ExceptionInterface instead.

@@ -7,15 +7,13 @@

namespace Zend\ServiceManager\Exception;

use Interop\Container\Exception\NotFoundException;
use Psr\Container\ContainerExceptionInterface;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alphabetical order please.

class ServiceNotFoundException extends SplInvalidArgumentException implements
ExceptionInterface,
NotFoundException
class ServiceNotFoundException extends SplInvalidArgumentException implements ContainerExceptionInterface
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The same here - I think we should implement just ExceptionInterface ... hm...and maybe NotFoundException? hm... but definitely ExceptionInterface instead of ContainerExceptionInterface.

use Interop\Container\ContainerInterface;
use Interop\Container\Exception\ContainerException;
use Psr\Container\ContainerExceptionInterface;
use Psr\Container\ContainerInterface;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alphabetical order please.

@@ -769,7 +769,7 @@ private function createDelegatorFromName($name, array $options = null)
* @throws ServiceNotFoundException if unable to resolve the service.
* @throws ServiceNotCreatedException if an exception is raised when
* creating a service.
* @throws ContainerException if any other error occurs
* @throws ContainerExceptionInterface|Exception if any other error occurs
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exception is very generic, I can't see where it is thrown.
And I think we should have separate @throws definition per exception.

@@ -781,7 +781,7 @@ private function doCreate($resolvedName, array $options = null)
} else {
$object = $this->createDelegatorFromName($resolvedName, $options);
}
} catch (ContainerException $exception) {
} catch (ContainerExceptionInterface $exception) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm... Can we use here ExceptionInterface maybe?

@michaelmoussa
Copy link
Author

@webimpress I gave you push access on my fork. I won't have time to go through a rebase until sometime next week unfortunately.

@michalbundyra
Copy link
Member

@michaelmoussa Thanks, I've rebased and pushed some changes.

@Ocramius Rebased, seems to be fine. Any chance to get it merged? 😄 Thanks!

@Ocramius Ocramius self-assigned this Feb 11, 2018
@Ocramius Ocramius merged commit 9a6b68f into zendframework:develop Feb 11, 2018
@Ocramius
Copy link
Member

@michaelmoussa @webimpress thanks 👍

@michalbundyra michalbundyra deleted the psr-11 branch February 12, 2018 07:35
@@ -16,11 +16,11 @@
*
* - rename the method `canCreateServiceWithName()` to `canCreate()`, and:
* - rename the `$serviceLocator` argument to `$container`, and change the
* typehint to `Interop\Container\ContainerInterface`
* typehint to `Psr\Container\ContainerInterface`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this was correct as it was previously noted for version 2 to version 3 migration

* - merge the `$name` and `$requestedName` arguments
* - rename the method `createServiceWithName()` to `__invoke()`, and:
* - rename the `$serviceLocator` argument to `$container`, and change the
* typehint to `Interop\Container\ContainerInterface`
* typehint to `Psr\Container\ContainerInterface`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this was correct as it was previously noted for version 2 to version 3 migration

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants