Consistent OPcache casing

Book/php5/build_system/building_extensions.rst

@@ -51,7 +51,7 @@ everything else. The reason is simply that building external extensions as share
 intrusive), as you will see in a moment. Another benefit is that you can update the extension without rebuilding PHP.
 
 .. [#] We'll explain the difference between a "normal" extension and a Zend extension later in the book. For now it
-       suffices to know that Zend extensions are more "low level" (e.g. opcache or xdebug) and hook into the workings of
+       suffices to know that Zend extensions are more "low level" (e.g. opcache or Xdebug) and hook into the workings of
        the Zend Engine itself.
 
 Installing extensions from PECL

Book/php7/extensions_design/hooks.rst

@@ -123,7 +123,7 @@ Modifying the Abstract Syntax Tree (AST)
 ****************************************
 
 When PHP 7 compiles PHP code it converts it into an abstract syntax tree (AST)
-before finally generating Opcodes that are persisted in Opcache. The
+before finally generating opcodes that are persisted in opcache. The
 ``zend_ast_process hook`` is called for every compiled script and allows you to
 modify the AST after it is parsed and created.
 
@@ -170,10 +170,10 @@ and all PHP scripts compiled after the replacement will be handled by your
 implementation of the hook.
 
 It is very important to always call the original function pointer, otherwise
-PHP cannot compile scripts anymore and Opcache will not work anymore.
+PHP cannot compile scripts anymore and opcache will not work anymore.
 
 The extension overwriting order here is also important as you need to be aware
-whether you want to register your hook before or after Opcache, because Opcache
+whether you want to register your hook before or after opcache, because opcache
 does not call the original function pointer if it finds an opcode array entry
 in its shared memory cache. Opcache registers their hook as a post startup
 hook, which runs after the minit phase for extensions, so by default your hook

Book/php7/extensions_design/zend_extensions.rst

@@ -103,7 +103,7 @@ Why need a Zend extension ?
 Let us warn you : until you have **very advanced** knowledge on PHP internal's Vritual Machine, and until you need to
 hook deep into it, you shouldn't need a Zend extension, but a PHP extension will be enough.
 
-Today's most commonly known Zend extensions into PHP's world are OPCache, XDebug, phpdbg and Blackfire. But you know
+Today's most commonly known Zend extensions into PHP's world are opcache, Xdebug, phpdbg and Blackfire. But you know
 dozens of PHP extensions next to that don't you ?! That's a clear sign that :
 
 * You should not need a Zend extension for a very big part of your problematics
@@ -215,7 +215,7 @@ In *practice*, what we can say about it is that :
   Until some distributions (FreeBSD hear us) change that ...
 
 * Zend extensions are triggered **before** PHP extensions when a request shows in. That means they got a chance to modify
-  the engine about the current request to come, so that PHP extensions use that modified context. OPCache uses such a
+  the engine about the current request to come, so that PHP extensions use that modified context. Opcache uses such a
   trick so that it can perform its complex tasks before any extension had a chance to prevent it to.
 
 * Same for request shutdown : Zend extensions can assume every PHP extension has shut down the request.
@@ -301,7 +301,7 @@ That's all for now. Let's fill-in those empty-body functions now::
 
 Like said before, ``message_handler()`` is a special hook that Zend extensions may declare to be noticed when another
 Zend extension get loaded. But be careful of the order. You must register our "pib" Zend extension first, then
-another Zend extension (like OPCache) after that, as the ``message_handler()`` is only called when a Zend extension is
+another Zend extension (like opcache) after that, as the ``message_handler()`` is only called when a Zend extension is
 loaded you obviously need to be loaded before to declare it. Chicken and egg.
 
 Then we'll start to dive into the engine, with our ``op_array_handler`` hook::
@@ -479,10 +479,10 @@ How is that possible ? And what for ?.
 Well there are several answers to such a question :
 
 * To :doc:`register new PHP functions <php_functions>`, a PHP extension is better than a Zend extension, as it already
-  knows how to do and has been designed for that specific purpose first. That would be pity not to use it. OPCache
+  knows how to do and has been designed for that specific purpose first. That would be pity not to use it. Opcache
   does that.
 * If you need to register about all the hooks in the full lifecycle, you'll obviously need both sides
-* If you need to master the order Zend extensions are loaded, f.e to get loaded after OPCache, you will need to be
+* If you need to master the order Zend extensions are loaded, f.e to get loaded after opcache, you will need to be
   hybrid
 
 The trick is simple, choose between :
@@ -656,7 +656,7 @@ Our PHP extension is effectively called "pib" and shows up, and our Zend extensi
 "pib-zend-extension" and shows up as well. We chose two different names for both parts, we could have chosen the same
 name.
 
-.. note:: OPCache and Xdebug use such an hybrid model, they are Zend extensions, but they need to publish PHP
+.. note:: Opcache and Xdebug use such an hybrid model, they are Zend extensions, but they need to publish PHP
           functions and thus they are also PHP extensions to do so.
 
 Hybrid PHP extension master, Zend extension slave

Book/php7/internal_types/strings/zend_strings.rst

@@ -250,9 +250,9 @@ Interned strings
 ----------------
 
 Just a quick word here about `interned strings <https://en.wikipedia.org/wiki/String_interning>`_. You could 
-need such a concept in extension development. Interned strings also interact with OPCache extension.
+need such a concept in extension development. Interned strings also interact with opcache extension.
 
-Interned strings are deduplicated strings. When used with OPCache, they also get reused from request to request.
+Interned strings are deduplicated strings. When used with opcache, they also get reused from request to request.
 
 Say you want to create the string "foo". What you tend to do is simply create a new string "foo"::
 
@@ -322,25 +322,25 @@ This process is in fact a little bit more complex than this. If you make use of
 :doc:`request processing <../../extensions_design/php_lifecycle>`, that string will be interned for sure.
 However, if you make use of an interned string as PHP is treating a request, then this string will only get interned for 
 the current request, and will get cleared after that.
-All this is valid if you don't use the OPCache extension, something you shouldn't do : use it.
+All this is valid if you don't use the opcache extension, something you shouldn't do : use it.
 
-When using the OPCache extension, if you make use of an interned string out of a 
+When using the opcache extension, if you make use of an interned string out of a 
 :doc:`request processing <../../extensions_design/php_lifecycle>`, that string will be 
 interned for sure and will also be shared to every PHP process or thread that will be spawned by you parallelism layer.
-Also, if you make use of an interned string as PHP is treating a request, this string will also get interned by OPCache 
+Also, if you make use of an interned string as PHP is treating a request, this string will also get interned by opcache 
 itself, and shared to every PHP process or thread that will be spawned by you parallelism layer.
 
-Interned strings mechanisms are then changed when OPCache extension fires in. OPCache not only allows to intern strings 
+Interned strings mechanisms are then changed when opcache extension fires in. Opcache not only allows to intern strings 
 that come from a request, but it also allows to share them to every PHP process of the same pool. This is done using 
-shared memory. When saving an interned string, OPCache will also add the ``IS_STR_PERMANENT`` flag to its GC info. 
+shared memory. When saving an interned string, opcache will also add the ``IS_STR_PERMANENT`` flag to its GC info. 
 That flag means the memory allocation used for the structure (``zend_string`` here) is permanent, it could be a shared 
 read-only memory segment.
 
 Interned strings save memory, because the same string is never stored more than once in memory. But it could waste some
 CPU time as it often needs to lookup the interned strings store, even if that process is well optimized yet.
 As an extension designer, here are global rules:
 
-* If OPCache is used (it should be), and if you need to create read-only strings : use an interned string.
+* If opcache is used (it should be), and if you need to create read-only strings : use an interned string.
 * If you need a string you know for sure PHP will have interned (a well-known-PHP-string, f.e "php" or "str_replace"),
   use an interned string.
 * If the string is not read-only and could/should be altered after its been created, do not use an interned string.

Book/php7/zend_engine.rst

@@ -3,7 +3,7 @@ Zend engine
 
 The Zend engine is a set of components that make PHP what it is. The most important Zend engine component is the
 *Zend Virtual Machine*, which is composed of the *Zend Compiler* and the *Zend Executor* components. We could also add
-the OPCache zend extension in such category. Those three components are the heart of PHP (or the brain, you choose),
+the opcache zend extension in such category. Those three components are the heart of PHP (or the brain, you choose),
 they are critical and they are the most complex parts of all the PHP source code. In the current chapter, we'll try to
 open them and detail them.
 

Book/php7/zend_engine/zend_opcache.rst

@@ -1,2 +1,2 @@
-Zend OPCache
+Zend opcache
 ============