Refactor SM

Author: bakura10

CHANGELOG.md

@@ -2,23 +2,229 @@
 
 All notable changes to this project will be documented in this file, in reverse chronological order by release.
 
-## 2.7.0 - TBD
+## v3.0.0 - TBD
 
 ### Added
 
-- Nothing.
+- You can now map multiple key names to the same factory. It was previously
+  possible in ZF2 but it was not enforced by the `FactoryInterface` interface.
+  Now the interface receives the `$requestedName` as the *second* parameter
+  (previously, it was the third).
+
+  Example:
+  
+  ```php
+  $sm = new \Zend\ServiceManager\ServiceManager([
+    'factories'  => [
+      MyClassA::class => MyFactory::class,
+      MyClassB::class => MyFactory::class
+    ]
+  ]);
+  
+  $sm->get(MyClassA::class); // MyFactory will receive MyClassA::class as second parameter
+  ```
+
+- Writing a plugin manager has been simplified. If you have simple needs, you no
+  longer need to implement the complete `validate` method.
+
+  In versions 2.x, if your plugin manager only allows creating instances that
+  implement `Zend\Validator\ValidatorInterface`, you needed to write the
+  following code:
+
+  ```php
+  class MyPluginManager extends AbstractPluginManager
+  {
+    public function validate($instance)
+    {
+        if ($instance instanceof \Zend\Validator\ValidatorInterface) {
+            return;
+        }
+    
+        throw new InvalidServiceException(sprintf(
+            'Plugin manager "%s" expected an instance of type "%s", but "%s" was received',
+             __CLASS__,
+             \Zend\Validator\ValidatorInterface::class,
+             is_object($instance) ? get_class($instance) : gettype($instance)
+        ));
+    }
+  }
+  ```
+  
+  In version 3, this becomes:
+  
+  ```php
+  class MyPluginManager extends AbstractPluginManager
+  {
+    protected $instanceOf = \Zend\Validator\ValidatorInterface::class;
+  }
+  ```
+  
+  Of course, you can still override the `validate` method if your logic is more
+  complex.
 
 ### Deprecated
 
-- Nothing.
+- Nothing
 
 ### Removed
 
-- Nothing.
+- Peering has been removed. It was a complex and rarely used feature that was
+  misunderstood most of the time.
 
-### Fixed
+- Integration with `Zend\Di` has been removed. It may be re-integrated later.
 
-- Nothing.
+- The `invokables` configuration key no longer exists. It has been replaced by a
+  built-in factory.
+
+  In versions 2.x:
+  
+  ```php
+  return [
+      'service_manager' => [
+          'invokables' => [
+              MyClass::class => MyClass:class,
+          ],
+      ],
+  ];
+  ```
+  
+  In ZF 3.x:
+  
+  ```php
+  return [
+      'service_manager' => [
+          'factories' => [
+              MyClass::class => 'Zend\ServiceManager\Factory\InvokableFactory',
+          ],
+      ],
+  ];
+  ```
+
+- `MutableCreationOptionsInterface` has been removed, as options can now be
+  passed directly through factories.
+
+- `ServiceLocatorAwareInterface` and its associated trait has been removed. It
+  was an anti-pattern, and you are encouraged to inject your dependencies in
+  factories instead of injecting the whole service locator.
+
+### Changed/Fixed
+
+v3 of the ServiceManager component is a completely rewritten, more efficient
+implementation of the service locator pattern. It includes a number of breaking
+changes, outlined in this section.
+
+- You no longer need a `Zend\ServiceManager\Config` object to configure the
+  service manager; you can pass the configuration array directly instead.
+
+  In version 2.x:
+  
+  ```php
+  $config = new \Zend\ServiceManager\Config([
+      'factories'  => [...]
+  ]);
+  
+  $sm = new \Zend\ServiceManager\ServiceManager($config);
+  ```
+  
+  In ZF 3.x:
+  
+  ```php
+  $sm = new \Zend\ServiceManager\ServiceManager([
+      'factories'  => [...]
+  ]);
+  ```
+
+- The ServiceManager is now immutable. Once configured, it cannot be altered.
+  You need to create a new service manager if you need to change the
+  configuration. This ensures safer and more aggressive caching. A new method,
+  `withConfig()` allows you to create a new instance that merges the provided
+  configuration.
+
+- Interfaces for `FactoryInterface`, `DelegatorFactoryInterface` and
+  `AbstractFactoryInterface` have changed. All are now directly invokable. This
+  allows a number of performance optimization internally.
+
+  Additionally, all signatures that accepted a "canonical name" argument now
+  remove it.
+
+  Most of the time, rewriting a factory to match the new interface implies
+  replacing the method name by `__invoke`, and removing the canonical name
+  argument if present.
+
+  For instance, here is a simple version 2.x factory:
+  
+  ```php
+  class MyFactory implements FactoryInterface
+  {
+      function createService(ServiceLocatorInterface $sl)
+      {
+          // ...
+      }
+  }
+  ```
+  
+  The equivalent version 3 factory:
+  
+  ```php
+  class MyFactory implements FactoryInterface
+  {
+      function __invoke(ServiceLocatorInterface $sl, $requestedName)
+      {
+          // ...
+      }
+  }
+  ```
+
+  Note another change in the above: factories also receive a second parameter,
+  enforced through the interface, that allows you to easily map multiple service
+  names to the same factory.
+
+- Plugin managers will now receive the parent service locator instead of itself
+  in factories. In version 2.x, you needed to call the method
+  `getServiceLocator()` to retrieve the parent (application) service locator.
+  This was confusing, and not IDE friendly as this method was not enforced
+  through the interface.
+
+  In version 2.x, if a factory was set to a service name defined in a plugin manager:
+  
+  ```php
+  class MyFactory implements FactoryInterface
+  {
+      function createService(ServiceLocatorInterface $sl)
+      {
+          // $sl is actually a plugin manager
+        
+          $parentLocator = $sl->getServiceLocator();
+        
+          // ...
+      }
+  }
+  ```
+  
+  In version 3:
+  
+  ```php
+  class MyFactory implements FactoryInterface
+  {
+      function __invoke(ServiceLocatorInterface $sl, $requestedName)
+      {
+          // $sl is already the main, parent service locator. If you need to
+          // retrieve the plugin manager again, you can retrieve it through the
+          // servicelocator:
+          $pluginManager = $sl->get(MyPluginManager::class);
+          // ...
+      }
+  }
+  ```
+
+  In practice, this should reduce code, as dependencies often come from the main
+  service locator, and not the plugin manager itself.
+
+- `PluginManager` now enforces the need for the main service locator in its
+  constructor. In v2.x, people often forgot to set the parent locator, which led
+  to bugs in factories trying to fetch dependencies from the parent locator.
+
+- It's so fast now that your app will fly!
 
 ## 2.6.1 - TBD
 

composer.json

@@ -3,8 +3,9 @@
     "description": " ",
     "license": "BSD-3-Clause",
     "keywords": [
-        "zf2",
-        "servicemanager"
+        "zf",
+        "servicemanager",
+        "service-manager"
     ],
     "homepage": "https://github.com/zendframework/zend-servicemanager",
     "autoload": {
@@ -17,21 +18,19 @@
         "container-interop/container-interop": "~1.0"
     },
     "require-dev": {
-        "zendframework/zend-di": "~2.5",
-        "zendframework/zend-mvc": "~2.5",
+        "phpunit/phpunit": "~4.6",
         "fabpot/php-cs-fixer": "1.7.*",
-        "phpunit/PHPUnit": "~4.0"
+        "ocramius/proxy-manager": "~1.0"
     },
     "suggest": {
-        "ocramius/proxy-manager": "ProxyManager 0.5.* to handle lazy initialization of services",
-        "zendframework/zend-di": "Zend\\Di component"
+        "ocramius/proxy-manager": "ProxyManager 1.* to handle lazy initialization of services"
     },
     "minimum-stability": "dev",
     "prefer-stable": true,
     "extra": {
         "branch-alias": {
             "dev-master": "2.6-dev",
-            "dev-develop": "2.7-dev"
+            "dev-develop": "3.0-dev"
         }
     },
     "autoload-dev": {