Miscellaneous improvements to wording.

Author: dhebbeker

doc/decisions/dr-004.md

@@ -91,7 +91,7 @@ The following variants of this option, specifies different methods to cope with
 
 #### Option 2a)
 
-Instead of directly using a modified Arduino interface (for example for a specific `class`), we use an adapter.
+Instead of directly using a modified Arduino interface provided by the extensions (for example for a specific `class`), we use an adapter.
 The adapters would be integrated just as for option 1.
 But compared to option 1 this only needs to be done for those smallest indivisible interfaces which are not compatible to the vanilla ACA.
 
@@ -113,8 +113,8 @@ Assuming that we do define interfaces for one or several HALs, we should not fol
 Because that would possibly complicate to write adapters for different HAL implementations.
 And allowing variants is one of the purposes of the adapters.
 
-Instead we would design the interfaces such that they fit the usage.
-In general an object oriented approach is sensible to represent the different components which are available through HALs.
+Instead we should design the interfaces such that they fit the usage.
+In general an object oriented approach is sensible to represent the different peripheral components which are available through HALs.
 Also an object oriented approach is the most straightforward to implement dependency inversion.
 
 This from those variants, **option 1a)** would be the best.
@@ -129,10 +129,10 @@ This from those variants, **option 1a)** would be the best.
     - Using a different implementation of our - to be defined - HAL interface would not require to modify the users of our HAL interface.
       Instead only a different adapter - implementing our HAL interface - would be required.[¹](<\ref dr004_1 "¹")
   - Cons:
-    - This approach requires to write adapters for all HAL interfaces to 3rd party libraries.
-      This is difficult and may result in boilerplate code.
-      Note, that this would mean to write adapters to a HAL implementation, which is an adapter (to proprietary peripheral drivers) in itself.
-- **Option 2a)**: Use adapters for extensions to vanilla ACA
+    - This approach requires to write adapters for all used HAL interfaces to 3rd party libraries.
+      A reusable interface is difficult to design and the adapters may result in boilerplate code.
+      Note, that this approach would mean to write adapters to a HAL implementation, which is an adapter (to proprietary peripheral drivers) in itself.
+- **Option 2a)**: Use adapters only for extensions to vanilla ACA
   - Pros:
     - Compared to option 1a), only a fraction of the adapters would need to be written.
   - Cons:
@@ -154,9 +154,9 @@ This from those variants, **option 1a)** would be the best.
     - In general conditionally compiled sections of code reduces its readability.
 
 \note \anchor dr004_1
-¹: Although, *in practice* our HAL interface may not be suitable to accommodate the new HAL implementation (see [Rule of Three](https://en.wikipedia.org/w/index.php%3Ftitle%3DRule_of_three_%28computer_programming%29%26oldid%3D1173684754)).
+¹: *In practice* our HAL interface may not be suitable to accommodate the new HAL implementation (see [Rule of Three](https://en.wikipedia.org/w/index.php%3Ftitle%3DRule_of_three_%28computer_programming%29%26oldid%3D1173684754)).
 Thus we would have to adjust our HAL interface and the code using it accordingly.
-In other words: It is difficult to design an HAL interface such that we would actually benefit when changing the HAL implementation to a different 3rd party library. Thus this advantage may not be relevant for that case.  
+In other words: It is difficult to design a HAL interface such that we would actually benefit when changing the HAL implementation to a different 3rd party library. Thus this advantage may not be relevant for that case.  
 Also - in case the HAL implementation is changed - it may be less effort to adjust all the uses of the new HAL interface than to write adapters for the changed 3rd party library.
 
 \note \anchor dr004_2
@@ -173,7 +173,7 @@ After careful consideration, we've decided on:
 
 And more specifically for testing on native environments, use:
 
-> **Option 2b):** Where the ACA is used it is allowed to add small conditionally compiled sections for tests in order to cope with deviations of the ACA used in productive code from the vanilla ACA.
+> **Option 2b):** Where the ACA is used, it is allowed to add small conditionally compiled sections for tests in order to cope with deviations of the ACA used in productive code from the vanilla ACA.
 
 The latter relaxation is in order to facilitate the use of ArduinoFake to stub the HAL's interface.