Fix typos in README and documentation

Documentation/Async.md

@@ -38,7 +38,7 @@ Alternatively you can inject an intermediary object that tracks the result of th
 
 ### <a id="example"></a>Example
 
-Lets see how we can inject async dependencies through an intermediary object. Async extensions implements `AsyncInject<T>` as this intermediary. You can use it as follows. 
+Let's see how we can inject async dependencies through an intermediary object. Async extensions implements `AsyncInject<T>` as this intermediary. You can use it as follows. 
 
 
 ```csharp
@@ -89,7 +89,7 @@ With the above `AsyncInject<IFoo>` binding, the instance is added to the contain
 
 Once injected to `Bar`, we can check whether the return value of the `async` operation is already available by calling the `TryGetResult`. method. This method will return `false` if there is no result to return. If result is not ready yet, we can listen to the `Completed` event to get the return value when the `async` operation completes.
 
-Alternatively we can use the  following methods to check the results availability.
+Alternatively we can use the  following methods to check the result's availability.
 ```csharp
 // Use HasResult to check if result exists 
 if (_asyncFoo.HasResult)

Documentation/DecoratorBindings.md

@@ -199,7 +199,7 @@ Container.Decorate&lt;<b>ContractType</b>&gt;()
 
 Where: 
 
-* **ContractType** = The type that is being decoratored.  An object of this type will be injected into the DecoratorType class.
+* **ContractType** = The type that is being decorated.  An object of this type will be injected into the DecoratorType class.
 
 * **DecoratorType** = The decorator class.  This should be a concrete type and also should take as an injected parameter/field an object of type ContractType.
 

Documentation/MemoryPools.md

@@ -37,7 +37,7 @@ Before understanding memory pools it would be helpful to understand factories, s
 
 It doesn't take long when developing games in Unity before you realize that proper memory management is very important if you want your game to run smoothly (especially on mobile).  Depending on the constraints of the platform and the type of game you are working on, it might be very important to avoid unnecessary heap allocations as much as possible.  One very effective way to do this is to use memory pools.
 
-As an example let's look at at a case where we are dynamically creating a class:
+As an example let's look at a case where we are dynamically creating a class:
 
 ```csharp
 public class Foo

Documentation/ReleaseNotes.md

@@ -118,7 +118,7 @@ Minor bug fixes, a few extra bind methods, and one minor breaking api change in
 Notable
 - Added new bind methods FromScriptableObject and FromNewScriptableObject bind methods for cases where you already have the ScriptableObject reference at install time
 - Added new subcontainer bind method ByInstanceGetter
-- Bug fix - the inject order was wrong in some rare edge cases (ie. sometimes objects would receive injected parameters that have not themsevles been injected yet)
+- Bug fix - the inject order was wrong in some rare edge cases (ie. sometimes objects would receive injected parameters that have not themselves been injected yet)
 - Bug fix - readonly properties were not injectable
 - Added ability to declare signals at runtime after install
 - Fixed playmode tests to work inside builds instead of just in editor
@@ -382,7 +382,7 @@ Minor release with just a few fixes.
 Notable
 - Fixes related to upgrading to Unity 5.6
 - Moved Zenject folder to plugins directory
-- Changed to trigger injection before Awake / OnEnable / Start for dynamically instantaited prefabs. This is nice because you can treat [Inject] methods more like constructors, and then use Awake/Start for initialization logic, for both dynamically created objects and objects in the scene at the start
+- Changed to trigger injection before Awake / OnEnable / Start for dynamically instantiated prefabs. This is nice because you can treat [Inject] methods more like constructors, and then use Awake/Start for initialization logic, for both dynamically created objects and objects in the scene at the start
 - Marked the [Inject] attribute with MeansImplicitUseAttribute to improve integration with JetBrains Resharper
 - Fixed bug that was happening when using ZenjectSceneLoader with LoadSceneMode.Single (it was destroying ProjectContext)
 - Added support for declaring [Inject] methods with return type IEnumerator similar to Start
@@ -469,7 +469,7 @@ Bug fixes
 - Fixed WithArguments bind method to support passing null values
 - Fixed context menu to work properly when creating installers etc. issue #200
 - Fixed issue with ZenUtilInternal.InjectGameObjectForComponent method to support looking up non-monobehaviours.
-- Fixed NonLazy() bind method to work properly wtihin sub containers
+- Fixed NonLazy() bind method to work properly within sub containers
 
 ---------
 
@@ -504,9 +504,9 @@ Bug fixes
 
 ## Version 4.5 (September 1, 2016)
 - Fixed DiContainer.ResolveTypeAll() method to properly search in parent containers
-- Fixed exception that was occuring with Factories when using derived parameter types
+- Fixed exception that was occurring with Factories when using derived parameter types
 - Fixed FromResolve to properly search in parent containers
-- Fixed exception that was occuring with FromMethod when using derived parameter types
+- Fixed exception that was occurring with FromMethod when using derived parameter types
 
 ---------
 
@@ -537,7 +537,7 @@ Bug fixes
 - (bug) Fixed PrefabFactory to work with abstract types
 - (bug) Fixed some bugs related to convention binding
 - (bug) Fixed bug with Unity 5.3.5 where the list of installers would not serialize properly
-- (but) Fixed minor bug with validation
+- (bug) Fixed minor bug with validation
 
 ---------
 
@@ -579,11 +579,11 @@ Bug fixes
 - Renamed GlobalCompositionRoot to ProjectCompositionRoot and FacadeCompositionRoot to GameObjectCompositionRoot.
 - Added more intuitive bindings for creating subcontainers. eg: Container.Bind().ToSubContainerResolve().ByPrefab()
 - Added WithGameObjectName and WithGroupName bind methods to prefab or game object related bindings
-- Made another big chagne to the fluent interface to avoid having duplicate methods for with Self and Concrete. Now you choose between Container.Bind().ToSelf() and Container.Bind().To(). ToSelf is assumed if unspecified
+- Made another big change to the fluent interface to avoid having duplicate methods for with Self and Concrete. Now you choose between Container.Bind().ToSelf() and Container.Bind().To(). ToSelf is assumed if unspecified
 - Changed Triggers to directly expose the signal event so they can be used as if they are signals
 - Added concept of ScriptableObjectInstaller - especially useful for use with settings
 - Added ZenjectSceneLoader class to allow additively loading other scenes as children or siblings of existing scene
-- Changed scene decorators to work more intuitively with the multi-scene editting features of Unity 5.3+. You can now drag in multiple scenes together, and as long as you use DecoratorCompositionRoot in scenes above a main scene, they will be loaded together.
+- Changed scene decorators to work more intuitively with the multi-scene editing features of Unity 5.3+. You can now drag in multiple scenes together, and as long as you use DecoratorCompositionRoot in scenes above a main scene, they will be loaded together.
 - Removed IncludeInactive flag. Now always injects into inactive game objects. This was kinda necessary because validation needs to control the active flag
 - Removed the concept of one single DependencyRoot in favour of having any number of them, using binding with identifier. Also added NonLazy() bind method to make this very easy
 - Added new attribute ZenjectAllowDuringValidation for use with installer setting objects that you need during validation
@@ -656,7 +656,7 @@ Bug fixes
 ## Version 3.2 (December 20, 2015)
 - Added the concept of "Commands" and "Signals".  See documentation for details.
 - Fixed validation for decorator scenes that open decorator scenes.
-- Changed to be more strict when using a combination of differents kinds of ToSingle<>, since there should only be one way to create the singleton.
+- Changed to be more strict when using a combination of different kinds of ToSingle<>, since there should only be one way to create the singleton.
 - Added ToSingleFactory bind method, for cases where you have complex construction requirements and don't want to use ToSingleMethod
 - Removed the InjectFullScene flag on SceneCompositionRoot.  Now always injects on the full scene.
 - Renamed AllowNullBindings to IsValidating so it can be used for other kinds of validation-only logic
@@ -669,7 +669,7 @@ Bug fixes
 - Added an Open button in scene decorator comp root for easily jumping to the decorated scene
 - Removed support for object graph visualization since I hadn't bothered maintaining it
 - Got the optional Moq extension method ToMock() working again
-- Fixed scene decorators to play more nicely with Unity's own way of handling LoadLevelAdditive.  Decorated scenes are now organized in the scene heirarchy under scene headings just like when calling LoadLevelAdditive normally
+- Fixed scene decorators to play more nicely with Unity's own way of handling LoadLevelAdditive.  Decorated scenes are now organized in the scene hierarchy under scene headings just like when calling LoadLevelAdditive normally
 
 ---------
 

Documentation/Signals.md

@@ -191,7 +191,7 @@ public class Greeter : IInitializable, IDisposable
 
 Note that if you go this route that you need to enable UniRx integration as described <a href="../README.md#unirx-integration">here</a>.
 
-As you can see in the the above examples, you can either directly bind a handler method to a signal in an installer using `BindSignal` (first example) or you can have your signal handler attach and detach itself to the signal (second and third examples)
+As you can see in the above examples, you can either directly bind a handler method to a signal in an installer using `BindSignal` (first example) or you can have your signal handler attach and detach itself to the signal (second and third examples)
 
 Details of how this works are explained in the following sections.
 
@@ -516,7 +516,7 @@ For example, Lets say I have a player and i want to save the game when i finish
 Ok easy, I create ``SignalLevelCompleted`` and then I subscribe it to my ``SaveGameSystem``
 then I also want to save when i reach a checkpoint, again i create ``SignalCheckpointReached``
 and then I subscribe it to my ``SaveGameSystem``
-you are begining to get something like this...
+you are beginning to get something like this...
 ```csharp
 public class Example
 {
@@ -588,10 +588,10 @@ public struct SignalLevelCompleted : ISignalGameSaver{}
 public interface ISignalGameSaver{}
 ```
 
-Now your ``SaveGameSystem`` doesnt knows about CheckPoints nor Level events, and just reacts to signals that save the game.
+Now your ``SaveGameSystem`` doesn't knows about CheckPoints nor Level events, and just reacts to signals that save the game.
 The main difference is in the Signal declaration and Firing
  - ``DeclareSignalWithInterfaces`` works like ``DeclareSignal`` but it declares the interfaces too.
- - ``AbstractFire`` is the same that ``Fire`` but it fires the interfacesjust if you have Declared the signal with interfaces 
+ - ``AbstractFire`` is the same that ``Fire`` but it fires the interfaces just if you have Declared the signal with interfaces 
  otherwise it will throw an exception.
 
 Ok, let's show even more power.
@@ -651,7 +651,7 @@ public interface ISignalAchievementUnlocker{ string AchievementKey {get;}}
 ```
 
 It offers a lot of modularity and abstraction for signals,
-you fire a concrete signal telling what you did and give them functionality trough Interface implementations
+you fire a concrete signal telling what you did and give them functionality through Interface implementations
 
 ### Signals With Subcontainers
 
@@ -667,7 +667,7 @@ In some cases it might be desirable to run a given signal asynchronously.  Async
 
 3. Unexpected state changes can occur while firing just one signal.  For example, an object A might trigger a signal which would trigger some logic that would eventually cause A to be deleted.  If the signal was executed synchronously, then the call stack could eventually return to object A where the signal was fired, and object A might then attempt to execute commands afterwards that causes problems (since object A will have already been deleted)
 
-This is not to say that asynchronous signals are superious to synchronous signals.  Asynchronous signals have their own risks as well.
+This is not to say that asynchronous signals are superior to synchronous signals.  Asynchronous signals have their own risks as well.
 
 1. Debugging can be more difficult, because it isn't clear from the stack trace where the signal was fired.
 

Documentation/SubContainers.md

@@ -23,7 +23,7 @@
 
 In some cases it can be very useful to use multiple containers in the same application.  For example, if you are creating a word processor it might be useful to have a sub-container for each tab that represents a separate document.  This way, you could bind a bunch of classes `AsSingle()` within the sub-container and they could all easily reference each other as if they were all singletons.  Then you could instantiate multiple sub-containers to be used for each document, with each sub-container having unique instances of all the classes that handle each specific document.
 
-Another example might be if you are designing an open-world space ship game, you might want each space ship to have it's own container that contains all the class instances responsible for running that specific spaceship.
+Another example might be if you are designing an open-world space ship game, you might want each space ship to have its own container that contains all the class instances responsible for running that specific spaceship.
 
 This is actually how ProjectContext bindings work.  There is one container for the entire project, and when a unity scene starts up, the container within each SceneContext is created "underneath" the ProjectContext container.  All the bindings that you add in your scene MonoInstaller are bound to your SceneContext container.  This allows the dependencies in your scene to automatically get injected with ProjectContext bindings, because sub-containers automatically inherit all the bindings in their parent (and grandparent, etc.).
 
@@ -92,7 +92,7 @@ Note the following:
 
 ## Creating Sub-Containers on GameObject's by using Game Object Context
 
-One issue with the <a href="#hello-world-for-facades">sub-container hello world example</a> above is that it does not work very well for MonoBehaviour classes.  There is nothing preventing us from adding MonoBehaviour bindings such as FromComponentInNewPrefab, FromNewComponentOnNewGameObject, etc. to our ByInstaller/ByMethod sub-container - however these will cause these new game objects to be added to the root of the scene heirarchy, so we'll have to manually track the lifetime of these objects ourselves by calling GameObject.Destroy on them when the Facade is destroyed.  Also, there is no way to have GameObject's that exist in our scene at the start but also exist within our sub-container.  Also, using ByInstaller and ByMethod like above does not support the use of interfaces such as IInitializable / ITickable / IDisposable inside the subcontainer.  These problems can be solved by using Game Object Context.
+One issue with the <a href="#hello-world-for-facades">sub-container hello world example</a> above is that it does not work very well for MonoBehaviour classes.  There is nothing preventing us from adding MonoBehaviour bindings such as FromComponentInNewPrefab, FromNewComponentOnNewGameObject, etc. to our ByInstaller/ByMethod sub-container - however these will cause these new game objects to be added to the root of the scene hierarchy, so we'll have to manually track the lifetime of these objects ourselves by calling GameObject.Destroy on them when the Facade is destroyed.  Also, there is no way to have GameObject's that exist in our scene at the start but also exist within our sub-container.  Also, using ByInstaller and ByMethod like above does not support the use of interfaces such as IInitializable / ITickable / IDisposable inside the subcontainer.  These problems can be solved by using Game Object Context.
 
 For this example, let's try to actually implement something similar to the open world space ship game described in <a href="#introduction">the sub-container introduction</a>:
 
@@ -213,7 +213,7 @@ public class ShipInputHandler : MonoBehaviour
 
 <img src="Images/ShipFacadeExample1.png?raw=true" alt="Ship Facade Example"/>
 
-* The idea here is that everything at or underneath the Ship game object should be considered inside it's own sub-container.  When we're done, we should be able to add multiple ships to our scene, each with their own components ShipHealthHandler, ShipInputHandler, etc. that can treat each other as singletons.
+* The idea here is that everything at or underneath the Ship game object should be considered inside its own sub-container.  When we're done, we should be able to add multiple ships to our scene, each with their own components ShipHealthHandler, ShipInputHandler, etc. that can treat each other as singletons.
 * Try to validate your scene by pressing `CTRL+ALT+V`.  You should get an error that looks like this: `Unable to resolve type 'ShipHealthHandler' while building object with type 'Ship'.`
 * This is because the ShipHealthHandler component has not been added to our sub-container.  To address this:
     * Click on the HealthHandler game object and then click Add Component and type Zenject Binding (see <a href="../README.md#scene-bindings">here</a> for details on this feature)
@@ -744,7 +744,7 @@ public class TestInstaller : MonoInstaller
 }
 ```
 
-Now, if we instantiate any game objects inside the Greeter subcontainer and we do not specify an explicit parent, then they will be placed underneath a new game object named "Greeter".  This can help for organization purposes when reading the scene in the scene heirarchy.
+Now, if we instantiate any game objects inside the Greeter subcontainer and we do not specify an explicit parent, then they will be placed underneath a new game object named "Greeter".  This can help for organization purposes when reading the scene in the scene hierarchy.
 
 Note also that with this approach, you can no longer use `BindExecutionOrder<Greeter>` to adjust the execution order of the subcontainer.  However, if you later decide that you need to customize the execution order then you can do that by passing a custom kernel-derived class to the WithKernel method and then using BindExecutionOrder with that class.  For example: