Update README.md

DevTeam · May 16, 2024 · 08c981d · 08c981d
1 parent e0239a4
commit 08c981d
Show file tree

Hide file tree

Showing 9 changed files with 29 additions and 17 deletions.
diff --git a/README.md b/README.md
@@ -79,7 +79,8 @@ class ShroedingersCat(Lazy<State> superposition) : ICat
 
 ```
 
-It is important to note that our abstraction and implementation knows nothing about the magic of DI or any frameworks.
+> [!IMPORTANT]
+> It is important to note that our abstraction and implementation knows nothing about the magic of DI or any frameworks.
 
 ### Let's glue it all together
 
@@ -165,9 +166,8 @@ class Program(IBox<ICat> box)
 
 The full analog of this application with top-level statements can be found [here](samples/ShroedingersCatTopLevelStatements).
 
-## To summarize
-
-_Pure.DI_ creates efficient code in a pure DI paradigm, using only basic language constructs as if you were writing code by hand. This allows you to take full advantage of Dependency Injection everywhere and always, without any compromise!
+> [!TIP]
+> _Pure.DI_ creates efficient code in a pure DI paradigm, using only basic language constructs as if you were writing code by hand. This allows you to take full advantage of Dependency Injection everywhere and always, without any compromise!
 
 <details>
 <summary>Just try!</summary>
@@ -407,7 +407,10 @@ In this case, the constructor with arguments is as follows:
 public Composition(string name, int id) { ... }
 ```
 
-and there is no default constructor. It is important to remember that only those arguments that are used in the object graph will appear in the constructor. Arguments that are not involved cannot be defined, as they are omitted from the constructor parameters to save resources.
+and there is no default constructor. 
+
+> [!IMPORTANT]
+> It is important to remember that only those arguments that are used in the object graph will appear in the constructor. Arguments that are not involved cannot be defined, as they are omitted from the constructor parameters to save resources.
 
 ### Scope constructor
 

diff --git a/readme/FooterTemplate.md b/readme/FooterTemplate.md
@@ -130,7 +130,10 @@ In this case, the constructor with arguments is as follows:
 public Composition(string name, int id) { ... }
 ```
 
-and there is no default constructor. It is important to remember that only those arguments that are used in the object graph will appear in the constructor. Arguments that are not involved cannot be defined, as they are omitted from the constructor parameters to save resources.
+and there is no default constructor. 
+
+> [!IMPORTANT]
+> It is important to remember that only those arguments that are used in the object graph will appear in the constructor. Arguments that are not involved cannot be defined, as they are omitted from the constructor parameters to save resources.
 
 ### Scope constructor
 

diff --git a/readme/ReadmeTemplate.md b/readme/ReadmeTemplate.md
@@ -39,7 +39,8 @@ class ShroedingersCat(Lazy<State> superposition) : ICat
 
 ```
 
-It is important to note that our abstraction and implementation knows nothing about the magic of DI or any frameworks.
+> [!IMPORTANT]
+> It is important to note that our abstraction and implementation knows nothing about the magic of DI or any frameworks.
 
 ### Let's glue it all together
 
@@ -125,9 +126,8 @@ class Program(IBox<ICat> box)
 
 The full analog of this application with top-level statements can be found [here](samples/ShroedingersCatTopLevelStatements).
 
-## To summarize
-
-_Pure.DI_ creates efficient code in a pure DI paradigm, using only basic language constructs as if you were writing code by hand. This allows you to take full advantage of Dependency Injection everywhere and always, without any compromise!
+> [!TIP]
+> _Pure.DI_ creates efficient code in a pure DI paradigm, using only basic language constructs as if you were writing code by hand. This allows you to take full advantage of Dependency Injection everywhere and always, without any compromise!
 
 <details>
 <summary>Just try!</summary>

diff --git a/readme/auto-bindings.md b/readme/auto-bindings.md
@@ -21,7 +21,8 @@ var composition = new Composition();
 var service = composition.MyService;
 ```
 
-:warning: But this approach cannot be recommended if you follow the dependency inversion principle and want your types to depend only on abstractions.
+> [!WARNING]
+> But this approach cannot be recommended if you follow the dependency inversion principle and want your types to depend only on abstractions.
 
 It is better to inject abstract dependencies, for example, in the form of interfaces. Use bindings to map abstract types to their implementations as in almost all [other examples](injections-of-abstractions.md).
 

diff --git a/readme/generic-composition-roots-with-constraints.md b/readme/generic-composition-roots-with-constraints.md
@@ -54,7 +54,8 @@ var service = composition.GetMyRoot<Stream, double>();
 var someOtherService = composition.GetOtherService<BinaryReader>();
 ```
 
-:warning: `Resolve' methods cannot be used to resolve generic composition roots.
+> [!IMPORTANT]
+> `Resolve' methods cannot be used to resolve generic composition roots.
 
 The following partial class will be generated:
 

diff --git a/readme/generic-composition-roots.md b/readme/generic-composition-roots.md
@@ -49,7 +49,8 @@ var service = composition.GetMyRoot<int>();
 var someOtherService = composition.GetOtherService<string>();
 ```
 
-:warning: `Resolve' methods cannot be used to resolve generic composition roots.
+> [!IMPORTANT]
+> `Resolve' methods cannot be used to resolve generic composition roots.
 
 The following partial class will be generated:
 

diff --git a/tests/Pure.DI.UsageTests/Basics/AutoBindingsScenario.cs b/tests/Pure.DI.UsageTests/Basics/AutoBindingsScenario.cs
@@ -2,8 +2,9 @@
 $v=true
 $p=0
 $d=Auto-bindings
-$h=Injection of non-abstract types is possible without any additional effort. 
-$f=:warning: But this approach cannot be recommended if you follow the dependency inversion principle and want your types to depend only on abstractions.
+$h=Injection of non-abstract types is possible without any additional effort.
+$f=> [!WARNING] 
+$f=> But this approach cannot be recommended if you follow the dependency inversion principle and want your types to depend only on abstractions.
 $f=
 $f=It is better to inject abstract dependencies, for example, in the form of interfaces. Use bindings to map abstract types to their implementations as in almost all [other examples](injections-of-abstractions.md).
 */

diff --git a/tests/Pure.DI.UsageTests/Generics/GenericCompositionRootsWithConstraintsScenario.cs b/tests/Pure.DI.UsageTests/Generics/GenericCompositionRootsWithConstraintsScenario.cs
@@ -2,7 +2,8 @@
 $v=true
 $p=4
 $d=Generic composition roots with constraints
-$f=:warning: `Resolve' methods cannot be used to resolve generic composition roots.
+$f=> [!IMPORTANT]
+$f=> `Resolve' methods cannot be used to resolve generic composition roots.
 */
 
 // ReSharper disable ClassNeverInstantiated.Local

diff --git a/tests/Pure.DI.UsageTests/Generics/GenericsCompositionRootsScenario.cs b/tests/Pure.DI.UsageTests/Generics/GenericsCompositionRootsScenario.cs
@@ -3,7 +3,8 @@
 $p=2
 $d=Generic composition roots
 $h=Sometimes you want to be able to create composition roots with type parameters. In this case, the composition root can only be represented by a method.
-$f=:warning: `Resolve' methods cannot be used to resolve generic composition roots.
+$f=> [!IMPORTANT]
+$f=> `Resolve' methods cannot be used to resolve generic composition roots.
 */
 
 // ReSharper disable ClassNeverInstantiated.Local