diff --git a/README.md b/README.md index 892e9f42..575776f2 100644 --- a/README.md +++ b/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 --------- diff --git a/doc/modules/ROOT/pages/getting-started.adoc b/doc/modules/ROOT/pages/getting-started.adoc index 6cedcb67..515a7cca 100644 --- a/doc/modules/ROOT/pages/getting-started.adoc +++ b/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"] diff --git a/doc/modules/ROOT/pages/index.adoc b/doc/modules/ROOT/pages/index.adoc index c30d4ee0..e3d1e70c 100644 --- a/doc/modules/ROOT/pages/index.adoc +++ b/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]. diff --git a/doc/modules/ROOT/pages/platform-and-genericity.adoc b/doc/modules/ROOT/pages/platform-and-genericity.adoc index 698277c9..4b522362 100644 --- a/doc/modules/ROOT/pages/platform-and-genericity.adoc +++ b/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 <>. // -//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 <>. diff --git a/doc/modules/core/pages/install.adoc b/doc/modules/core/pages/install.adoc index e1852440..c680f7a5 100644 --- a/doc/modules/core/pages/install.adoc +++ b/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 diff --git a/doc/modules/core/pages/modules-inheritance.adoc b/doc/modules/core/pages/modules-inheritance.adoc index 8cb4a03a..5bfc9b05 100644 --- a/doc/modules/core/pages/modules-inheritance.adoc +++ b/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 { 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().foo` and `child.instance().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. diff --git a/doc/modules/core/pages/using-environment.adoc b/doc/modules/core/pages/using-environment.adoc index 78317fca..a86d37be 100644 --- a/doc/modules/core/pages/using-environment.adoc +++ b/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) diff --git a/doc/modules/extension/pages/jsr330.adoc b/doc/modules/extension/pages/jsr330.adoc index 01e6b0de..bb5cd213 100644 --- a/doc/modules/extension/pages/jsr330.adoc +++ b/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. diff --git a/doc/modules/framework/pages/compose.adoc b/doc/modules/framework/pages/compose.adoc index 283ed59e..aa2be321 100644 --- a/doc/modules/framework/pages/compose.adoc +++ b/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_*. diff --git a/doc/modules/framework/pages/ktor.adoc b/doc/modules/framework/pages/ktor.adoc index 1419b6e3..2bff611d 100644 --- a/doc/modules/framework/pages/ktor.adoc +++ b/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. ==== diff --git a/doc/modules/framework/pages/tornadofx.adoc b/doc/modules/framework/pages/tornadofx.adoc index 2c533812..b400b1b1 100644 --- a/doc/modules/framework/pages/tornadofx.adoc +++ b/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 diff --git a/doc/modules/migration/pages/migration-4to5.adoc b/doc/modules/migration/pages/migration-4to5.adoc index 1a210f38..5ad078a6 100644 --- a/doc/modules/migration/pages/migration-4to5.adoc +++ b/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. diff --git a/doc/modules/migration/pages/migration-6to7.adoc b/doc/modules/migration/pages/migration-6to7.adoc index dccb8f0c..bfc5784a 100644 --- a/doc/modules/migration/pages/migration-6to7.adoc +++ b/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`.