Merge branch 'feature/spelling' of https://github.com/ka7/zend-servicemanager into feature/189

Author: asgrim

doc/book/configuring-the-service-manager.md

@@ -13,7 +13,7 @@ constructor. The following keys are:
 - `initializers`: a list of callable or initializers that are run whenever a service has been created.
 - `shared`: associative array that map a service name to a boolean, in order to
   indicate the service manager if it should cache or not a service created
-  through the `get` method, independant of the `shared_by_default` setting.
+  through the `get` method, independent of the `shared_by_default` setting.
 - `lazy_services`: configuration for the lazy service proxy manager, and a class
   map of service:class pairs that will act as lazy services; see the
   [lazy services documentation](lazy-services.md) for more details.
@@ -423,7 +423,7 @@ So far, we have covered examples where services are created through factories
 Occasionally you may need to pass additional options that act as a "context".
 For instance, we could have a `StringLengthValidator` service registered.
 However, this validator can have multiple options, such as `min` and `max`.
-Because this is dependant on the caller context (or might even be retrieved
+Because this is dependent on the caller context (or might even be retrieved
 from a database, for instance), the factory cannot know what options to give
 when constructing the validator.
 

doc/book/cookbook/factories-vs-abstract-factories.md

@@ -57,7 +57,7 @@ This means, internally:
 - a hash table lookup (for the abstract factory)
 - invocation of 1:N methods for discovery
     - which may contain additional lookups and/or retrievals in the container
-- invocation of a factory method (assuming succesful lookup)
+- invocation of a factory method (assuming successful lookup)
 
 As such, having an explicit map can aid performance dramatically.