Merge pull request #390 from wiryadev/fix-typo

README.md

@@ -56,7 +56,7 @@ class Controller(private di: DI) {
 - It can be used in plain Java
 
 ### Looking for **Kodein-DI 7.0** migration guide?
-> Folow this us [here](https://kodein.org/Kodein-DI/?7.0/migration-6to7).
+> Follow this us [here](https://kodein.org/Kodein-DI/?7.0/migration-6to7).
 
 Kotlin & JVM compatibility
 ---------

doc/modules/ROOT/pages/getting-started.adoc

@@ -79,7 +79,7 @@ dependencies {
 }
 ----
 
-You need to activate the preview feature `GRADLE_METADATA` in your _.setings.gradle.kts_ file.
+You need to activate the preview feature `GRADLE_METADATA` in your _.settings.gradle.kts_ file.
 
 .setings.gradle.kts
 [source,kotlin,subs="attributes"]

doc/modules/ROOT/pages/index.adoc

@@ -27,7 +27,7 @@ _Kodein-DI_ is a very useful dependency injection / retrieval container, it is v
 
 Contributions are very welcome and greatly appreciated! The great majority of pull requests are eventually merged.
 
-To contribute, simply fork https://github.com/Kodein-Framework/Kodein-DI[the project on Github], fix whatever is iching you, and submit a pull request!
+To contribute, simply fork https://github.com/Kodein-Framework/Kodein-DI[the project on Github], fix whatever is itching you, and submit a pull request!
 
 I am sure that this documentation contains typos, inaccuracies and languages error (English is not my mother tongue).
 If you feel like enhancing this document, you can propose a pull request that modifies https://github.com/Kodein-Framework/Kodein-DI/tree/master/doc[the documentation documents].

doc/modules/ROOT/pages/platform-and-genericity.adoc

@@ -57,7 +57,7 @@ Therefore, please make sure that, using the erased version is right for your use
 //- You are confident you are not binding / injecting / retrieving generic types and you are sure *none of the libraries you are using are*.
 //- You are not using <<set-bindings,set bindings>>.
 //
-//If you profile your code and find that injection is a performance pitfall, then it probably is instanciation: you are creating too many objects in critical paths.
+//If you profile your code and find that injection is a performance pitfall, then it probably is instantiation: you are creating too many objects in critical paths.
 //Reusing objects in critical paths will enhance performance both in dependency injection / retrieval and in GC!
 //
 //If you are using the `erased` version, either by choice on the JVM, or by default on JS & Native, you should read <<erased-version,erased version pitfalls>>.

doc/modules/core/pages/install.adoc

@@ -64,7 +64,7 @@ _Kodein-DI_ uses the new gradle native dependency model.
 
 [TIP]
 ====
-If you are *NOT* using *Gradle 6+*, you must declare the use of the Gralde Metadata experimental feature
+If you are *NOT* using *Gradle 6+*, you must declare the use of the Gradle Metadata experimental feature
 
 [subs="attributes"]
 .settings.gradle.kts

doc/modules/core/pages/modules-inheritance.adoc

@@ -110,7 +110,7 @@ However, when intended, it can be really interesting to override a binding, espe
 You can override an existing binding by specifying explicitly that it is an override.
 
 [source, kotlin]
-.Example: binds twice the same type, the second time explitly specifying an override
+.Example: binds twice the same type, the second time explicitly specifying an override
 ----
 val di = DI {
     bind<API> { singleton { APIImpl() } }
@@ -184,7 +184,7 @@ Because the `Bar` binding is a `singleton` and is declared in the `parent` _Kode
 In this example, both `parent.instance<Bar>().foo` and `child.instance<Bar>().foo` will yield a `Foo1` object.
 
 NOTE: This is because `Bar` is bound to a `singleton`, the first access would define the container used (`parent` or `child`).
-If the singleton were initialized by `child`, then a subsequent access from `parent` would yeild a `Bar` with a reference to a `Foo2`, which is not supposed to exist in `parent`.
+If the singleton were initialized by `child`, then a subsequent access from `parent` would yield a `Bar` with a reference to a `Foo2`, which is not supposed to exist in `parent`.
 
 IMPORTANT: By default, *all bindings that do not cache instances* (basically all bindings but `singleton` and `multiton`) *are copied by default into the new container*, and therefore have access to the bindings & overrides of this new container.
 

doc/modules/core/pages/using-environment.adoc

@@ -8,7 +8,7 @@ Binding functions have access to the environment where the bound type is retriev
 [.lead]
 This environment is represented as a *context* variable.
 
-The context is an object that is explicitly defined by the programmer for this retrieval or the receiving object when none is explicitely defined.
+The context is an object that is explicitly defined by the programmer for this retrieval or the receiving object when none is explicitly defined.
 
 There are two very important differences between a tag and a context:
 
@@ -128,7 +128,7 @@ val di = DI {
 
 `WeakContextScope.of` will always return the same scope, which you should never clean!
 
-If you need a compartimentalized scope which you can clean, you can create a new `WeakContextScope`:
+If you need a compartmentalized scope which you can clean, you can create a new `WeakContextScope`:
 
 [source, kotlin]
 .Example: creating a WeakContextScope.
@@ -158,7 +158,7 @@ This allows you to retrieve a `User` instance:
 - When there is a global `Request` context:
 +
 [source, kotlin]
-.Example: retriving with a global context
+.Example: retrieving with a global context
 ----
 class MyController(override val di: DI, request: Request): DIAware {
     override val diContext = kcontext(request)

doc/modules/extension/pages/jsr330.adoc

@@ -7,7 +7,7 @@ Kodein-DI offers a module that implements reflexivity injection based on the JSR
 There are two reasons to use this module:
 
 - You are moving a code base from a Java injection library (such as Guice or Dagger) and want the Java code to work the same while there still is injected java code.
-- You want to easilly use Kodein-DI in a Java code.
+- You want to easily use Kodein-DI in a Java code.
 - That's it!
 
 Using this module with Kotlin code means adding a lot of reflexivity at run-time that can easily be avoided in Kotlin (but not in Java).
@@ -197,7 +197,7 @@ public class MyJavaController {
 }
 ----
 
-=== Optionnal injection
+=== Optional injection
 
 If you need to inject something only if it was bound (and set it to null otherwise), you can use the `@OrNull` annotation.
 

doc/modules/framework/pages/compose.adoc

@@ -314,7 +314,7 @@ WARNING: Under the hood these functions are using `LocalDI`. If there is no DI c
 This gives us the ability to combine two important concepts that are xref:core:injection-retrieval.adoc#di-aware[`DIAware`] and the xref:android.adoc#closest-di[closest DI pattern].
 It adds to some Android specific objects, an extension function `di()`, that is capable of exploring the context hierarchy until it finds a DI container, hence the name of the pattern.
 
-Thanks to these mechanisms we can provide two specifcs functions for *_Jetpack Compose_* users.
+Thanks to these mechanisms we can provide two specifics functions for *_Jetpack Compose_* users.
 
 1. A `@Composable` function `androidContextDI` that uses the closest DI pattern to get a DI container by using the link:https://developer.android.com/reference/kotlin/androidx/compose/runtime/CompositionLocal[CompositionLocal] `LocalContext`, from *_Jetpack Compose_*.
 

doc/modules/framework/pages/ktor.adoc

@@ -192,7 +192,7 @@ WARNING: If you define multiple `routing { }` features, Ktor have a specific way
 
 WARNING: The `subDI` mechanism will only work if your Ktor `Application` has the `DIFeature` installed, or if you handle the installation manually.
 
-NOTE: On the contrary you can define a `subDI { }` object for each of your `Route`s as each of them will be able to embbed a DI instance.
+NOTE: On the contrary you can define a `subDI { }` object for each of your `Route`s as each of them will be able to embed a DI instance.
 
 .*Copying bindings*
 
@@ -466,7 +466,7 @@ Only their routes defined in the `Route.getRoutes` will be reachable on the web
 
 [CAUTION]
 ====
-`Route.controller` extension functions and `DIControllerFeature` can be used at the same time but we recommand that you *should not*
+`Route.controller` extension functions and `DIControllerFeature` can be used at the same time but we recommend that you *should not*
 Declaring controllers in the `Route.controller` extension functions and the `DIControllerFeature` might install the same route multiple times, thus leading to exceptions.
 ====
 

doc/modules/framework/pages/tornadofx.adoc

@@ -148,7 +148,7 @@ class PersonListController : Controller(), DIAware { <1>
     /*...*/
 }
 ----
-<1> Set the Controller as `KodeeinAware`
+<1> Set the Controller as `KodeinAware`
 <2> Retrieve the `App` DI container from the `kodeinDI()` extension function
 <3> Retrieve dependency using the `instance()` function, as the DI container is part of the context
 <4> Use the dependency

doc/modules/migration/pages/migration-4to5.adoc

@@ -46,7 +46,7 @@ Kodein is now located inside the package `org.kodein.di`.
 The biggest change in Kodein 5 is that everything in Kodein 5 is lazy. +
 This is because:
 
-- You shouldn't know whether the instance you are asking for will be easy to reatrieve or hard to construct.
+- You shouldn't know whether the instance you are asking for will be easy to retrieve or hard to construct.
 - Some classes (such as Android or TornadoFX components) are created before being "attached" to their context.
 
 Furthermore, the use of Kotlin's delegated properties allows:
@@ -92,7 +92,7 @@ TIP: Kodein 5 also allows the binding factories to access the receiver of the pr
      This is very useful for framework integration such as Android & TornadoFX.
 
 The `Singleton` binding is now supercharged.
-It handles scopes AND references, which means that it is now possible for weird stuff such as "weaked scoped singleton".
+It handles scopes AND references, which means that it is now possible for weird stuff such as "weakened scoped singleton".
 
 TIP: The `multiton` binding is the same!
 
@@ -390,7 +390,7 @@ class MyController(request: Request) : KodeinAware {
 }
 ----
 
-NOTE: Setting a `kodeinContext` still allows you to acces bindings without scopes!
+NOTE: Setting a `kodeinContext` still allows you to access bindings without scopes!
       The `kodeinContext` is the context _by default_, but will not be used if there is no need for a context.
 
 

doc/modules/migration/pages/migration-6to7.adoc

@@ -44,7 +44,7 @@ TIP: Differences are subtle, please read the xref:ROOT:index.adoc[full documenta
 
 === Class renaming: *Kodein* -> *DI*
 
-New libraries have been released under the *Kodein Frameowrk*, like *Kodein-DB*.
+New libraries have been released under the *Kodein Framework*, like *Kodein-DB*.
 Thus, we thought that is was legit to change the `Kodein` part of our class names, in the benefit of an more explicit one `DI`.
 
 Basically, every classes that were named after `Kodein` have been renamed with `DI`, like `KodeinAware` -> `DIAware`.