typo fix

Author: rssh

2024_12_09_dependency-injection.md

@@ -27,7 +27,7 @@ If we switch to type-driven context resolving (i.e., use `AppContext[Service1]`
 The first look was at the approach described by @odersky in https://old.reddit.com/r/scala/comments/1eksdo2/automatic_dependency_injection_in_pure_scala/.
 (code:  https://github.com/scala/scala3/blob/main/tests/run/Providers.scala )
 
-Unfortunately, the proposed technique is not directly applicable to our cases. The main reason is that machinery with math types works only when all types in the tuple are distinct.  Therefore, this means all components participating in dependency injection should not be traits. (because if we have two traits (A, B),  we can't prove that A and B in general are distinct; therefore, Index[(A, B)] will not resolved.  The limitation not to use traits as components is too strict for practical usage.  Two other problems (absence of chaining of providers and absence of caching) are fixable and demonstrate a usual gap between 'proof of concept’ and real stuff.
+Unfortunately, the proposed technique is not directly applicable to our cases. The main reason is that machinery with matсh types works only when all types in the tuple are distinct.  Therefore, this means all components participating in dependency injection should not be traits. (because if we have two traits (A, B),  we can't prove that A and B in general are distinct; therefore, Index[(A, B)] will not resolved.  The limitation not to use traits as components is too strict for practical usage.  Two other problems (absence of chaining of providers and absence of caching) are fixable and demonstrate a usual gap between 'proof of concept’ and real stuff.
 
 We will use approaches very close to what sideEffffECt describe in https://www.reddit.com/r/scala/comments/1eqqng2/the_simplest_dependency_injection_pure_scala_no/ with few additional steps.