Minor tweaks for the article that explains the new 3.3 DI features

service_container/3.3-di-changes.rst

@@ -8,19 +8,19 @@ without sacrificing predictability, which is very important! Another goal is to
 controllers and services behave more consistently. In Symfony 3.3, controllers *are*
 services by default.
 
-The documentation has already been updated to assume you have these new features enabled.
-If you're an existing Symfony user and want to understand the "what" and "why" behind
-these changes, this chapter is for you!
+The documentation has already been updated to assume you have these new features
+enabled. If you're an existing Symfony user and want to understand the "what"
+and "why" behind these changes, this article is for you!
 
-All Changes are Opt-In
-----------------------
+All Changes are Optional
+------------------------
 
 Most importantly, **you can upgrade to Symfony 3.3 today without making any changes to your app**.
 Symfony has a strict :doc:`backwards compatibility promise </contributing/code/bc>`,
 which means it's always safe to upgrade across minor versions.
 
-All of the new features are **opt-in**: you need to actually change your configuration
-files to use them.
+All of the new features are **optional**: they are not enabled by default, so you
+need to actually change your configuration files to use them.
 
 The new Default services.yml File
 ---------------------------------
@@ -151,7 +151,7 @@ thanks to the following config:
         // services cannot be automatically loaded with PHP configuration
         // you need to define your services one-by-one
 
-This means that every class in ``src/AppBundle`` is *available* to be used as a
+This means that every class in ``src/AppBundle/`` is *available* to be used as a
 service. And thanks to the ``_defaults`` section at the top of the file, all of
 these services are **autowired** and **private** (i.e. ``public: false``).
 
@@ -166,7 +166,7 @@ to determine most arguments automatically. But, you can always override the serv
 and :ref:`manually configure arguments <services-manually-wire-args>` or anything
 else special about your service.
 
-    But wait, if I have some model (non-service) classes in my ``src/AppBundle``
+    But wait, if I have some model (non-service) classes in my ``src/AppBundle/``
     directory, doesn't this mean that *they* will also be registered as services?
     Isn't that a problem?
 
@@ -230,12 +230,12 @@ To pass the ``InvoiceGenerator`` as an argument to ``InvoiceMailer``, you needed
 to specify the service's *id* as an argument: ``app.invoice_generator``. Service
 id's were the main way that you configured things.
 
-But in Symfony 3.3, thanks to autowiring, all you need to do is type-hint the argument
-with ``InvoiceGenerator``::
+But in Symfony 3.3, thanks to autowiring, all you need to do is type-hint the
+argument with ``InvoiceGenerator``::
 
     // src/AppBundle/Service/InvoiceMailer.php
     // ...
-    
+
     class InvoiceMailer
     {
         private $generator;
@@ -288,7 +288,7 @@ was designed with that in mind. Specifically:
   a service whose id matches the type-hint exactly. It does *not* scan all services
   looking for objects that have that class/interface (actually, it *does* do this
   in Symfony 3.3, but has been deprecated. If you rely on this, you will see a clear
-  deprecation warning). 
+  deprecation warning).
 
 Autowiring aims to *automate* configuration without magic.
 
@@ -387,7 +387,7 @@ create the class::
 
     // src/AppBundle/EventSubscriber/SetHeaderSusbcriber.php
     // ...
-    
+
     use Symfony\Component\EventDispatcher\EventSubscriberInterface;
     use Symfony\Component\HttpKernel\Event\FilterResponseEvent;
     use Symfony\Component\HttpKernel\KernelEvents;
@@ -398,7 +398,7 @@ create the class::
         {
             $event->getResponse()->headers->set('X-SYMFONY-3.3', 'Less config');
         }
-    
+
         public static function getSubscribedEvents()
         {
             return [
@@ -499,8 +499,8 @@ Start by adding a ``_defaults`` section with ``autowire`` and ``autoconfigure``.
         # ...
 
 This step is easy: you're already *explicitly* configuring all of your services.
-So, ``autowire`` does nothing. You're also already tagging your services, so ``autoconfigure``
-also doesn't change any existing services.
+So, ``autowire`` does nothing. You're also already tagging your services, so
+``autoconfigure`` also doesn't change any existing services.
 
 You have not added ``public: false`` yet. That will come in a minute.
 
@@ -574,7 +574,7 @@ Now you're ready to default all services to be private:
 
     # app/config/services.yml
     # ...
-    
+
     services:
          _defaults:
              autowire: true
@@ -592,7 +592,7 @@ instances of the same class), you may need to make those public:
 
     # app/config/services.yml
     # ...
-    
+
     services:
         # ...
 
@@ -602,7 +602,7 @@ instances of the same class), you may need to make those public:
     +        # remove this if/when you are not fetching this
     +        # directly from the container via $container->get()
     +        public: true
- 
+
          app.api_client_sl_connect:
              # ...
     +        public: true
@@ -614,8 +614,8 @@ clean that up.
 Step 4) Auto-registering Services
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-You're now ready to automatically register all services in ``src/AppBundle`` (and/or
-any other directory/bundle you have):
+You're now ready to automatically register all services in ``src/AppBundle/``
+(and/or any other directory/bundle you have):
 
 .. code-block:: diff
 
@@ -697,7 +697,7 @@ these directly from the container, you can remove the ``public: true`` flag:
          app.api_client_github:
              # ...
     -        public: true
- 
+
          app.api_client_sl_connect:
              # ...
     -        public: true