Merge branch 'refactor-sm' into develop

Close #9

V3, here we come!

Author: weierophinney

.php_cs

@@ -41,7 +41,7 @@ install:
 script:
   - if [[ $EXECUTE_TEST_COVERALLS == 'true' ]]; then ./vendor/bin/phpunit --coverage-clover clover.xml ; fi
   - if [[ $EXECUTE_TEST_COVERALLS != 'true' ]]; then ./vendor/bin/phpunit ; fi
-  - if [[ $EXECUTE_CS_CHECK == 'true' ]]; then ./vendor/bin/php-cs-fixer fix -v --diff --dry-run ; fi
+  - if [[ $EXECUTE_CS_CHECK == 'true' ]]; then ./vendor/bin/phpcs ; fi
 
 after_script:
   - if [[ $EXECUTE_TEST_COVERALLS == 'true' ]]; then ./vendor/bin/coveralls ; fi

.travis.yml

@@ -2,23 +2,233 @@
 
 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,
+          'MyClassC'      => 'MyFactory' // This is equivalent as using ::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
+  use Zend\ServiceManager\AbstractPluginManager;
+  use Zend\Validator\ValidatorInterface;
+  
+  class MyPluginManager extends AbstractPluginManager
+  {
+      protected $instanceOf = 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
 

CHANGELOG.md

@@ -77,24 +77,24 @@ To do so:
 
 ## Running Coding Standards Checks
 
-This component uses [php-cs-fixer](http://cs.sensiolabs.org/) for coding
+This component uses [phpcs](https://github.com/squizlabs/PHP_CodeSniffer) for coding
 standards checks, and provides configuration for our selected checks.
-`php-cs-fixer` is installed by default via Composer.
+`phpcs` is installed by default via Composer.
 
 To run checks only:
 
 ```console
-$ ./vendor/bin/php-cs-fixer fix . -v --diff --dry-run --config-file=.php_cs
+$ ./vendor/bin/phpcs
 ```
 
-To have `php-cs-fixer` attempt to fix problems for you, omit the `--dry-run`
-flag:
+`phpcs` provides another tool, `phpcbf`, that can automatically fix many common
+problems:
 
 ```console
-$ ./vendor/bin/php-cs-fixer fix . -v --diff --config-file=.php_cs
+$ ./vendor/bin/phpcbf
 ```
 
-If you allow php-cs-fixer to fix CS issues, please re-run the tests to ensure
+If you allow `phpcbf` to fix CS issues, please re-run the tests to ensure
 they pass, and make sure you add and commit the changes after verification.
 
 ## Recommended Workflow for Contributions

CONTRIBUTING.md

@@ -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",
-        "fabpot/php-cs-fixer": "1.7.*",
-        "phpunit/PHPUnit": "~4.0"
+        "phpunit/phpunit": "~4.6",
+        "ocramius/proxy-manager": "~1.0",
+        "squizlabs/php_codesniffer": "^2.0@dev"
     },
     "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": {