Editorial change: renaming course to "Ada In Practice"

content/courses/ada-idioms/chapters/abstract_data_machines.rst → content/courses/ada-in-practice/chapters/abstract_data_machines.rst

@@ -1,4 +1,4 @@
-.. _Ada_Idioms_Abstract_Data_Machines:
+.. _Ada_In_Practice_Abstract_Data_Machines:
 
 Abstract Data Machines
 ======================
@@ -22,7 +22,7 @@ How can the software representing the abstraction best implement this
 requirement?
 
 The Abstract Data Type (ADT) :ref:`Abstract Data Type
-<Ada_Idioms_Abstract_Data_Types>` idiom is the primary abstraction
+<Ada_In_Practice_Abstract_Data_Types>` idiom is the primary abstraction
 definition facility in Ada. Given an ADT that provides the required
 facility you could simply declare a single object of the type. But how
 could you ensure that some other client, perhaps in the future, doesn't
@@ -45,7 +45,7 @@ implementation only creates one such object, so multiple object
 declarations are precluded.
 
 Singletons can be expressed easily in Ada
-:ref:`Controlling Object Initialization and Creation <Ada_Idioms_Controlling_Object_Initialization_And_Creation>`
+:ref:`Controlling Object Initialization and Creation <Ada_In_Practice_Controlling_Object_Initialization_And_Creation>`
 but there is an alternative in this specific situation.
 
 This idiom entry describes the alternative, known as the Abstract Data
@@ -134,7 +134,7 @@ Consider the following ADM version of the package :ada:`Integer_Stacks`, now
 renamed to :ada:`Integer_Stack` for reasons we will discuss shortly. In this
 version we declare the state in the package body.
 
-.. _Ada_Idioms_Abstract_Data_Machines_Code_Example:
+.. _Ada_In_Practice_Abstract_Data_Machines_Code_Example:
 
 .. code-block:: ada
 
@@ -242,7 +242,7 @@ declare the data in the package body.
 The ADM idiom applies information hiding to the internal state, like the
 ADT idiom, except that the state is not in an object declared by the
 client. Also, like the :ref:`Groups of Related Program Units
-<Ada_Idioms_Groups_Of_Related_Program_Units>`, the implementations of
+<Ada_In_Practice_Groups_Of_Related_Program_Units>`, the implementations of
 the visible subprograms are hidden in the package body, along with any
 non-visible entities required for their implementation.
 

content/courses/ada-idioms/chapters/abstract_data_types.rst → content/courses/ada-in-practice/chapters/abstract_data_types.rst

@@ -1,4 +1,4 @@
-.. _Ada_Idioms_Abstract_Data_Types:
+.. _Ada_In_Practice_Abstract_Data_Types:
 
 Abstract Data Types
 ===================
@@ -9,7 +9,7 @@ Motivation
 ----------
 
 In the
-:ref:`Groups of Related Program Units <Ada_Idioms_Groups_Of_Related_Program_Units>` idiom,
+:ref:`Groups of Related Program Units <Ada_In_Practice_Groups_Of_Related_Program_Units>` idiom,
 client compile-time visibility to the type's representation is both an
 advantage and a disadvantage. Visibility to the representation makes available
 the expressiveness of low-level syntax, such as array indexing and aggregates,
@@ -26,7 +26,7 @@ bound. The likely representation for the :ada:`Stack` type will require both
 an array for the contained values and a *stack pointer* indicating the *top* of
 the stack. Hence this will be a composite type, probably a record type. If we
 use the
-:ref:`Groups of Related Program Units <Ada_Idioms_Groups_Of_Related_Program_Units>`
+:ref:`Groups of Related Program Units <Ada_In_Practice_Groups_Of_Related_Program_Units>`
 idiom the code might look like this:
 
 .. code-block:: ada
@@ -166,7 +166,7 @@ internal representation.
 Consider the following revision to the package :ada:`Integer_Stacks`, now as
 an ADT:
 
-.. _Ada_Idioms_Abstract_Data_Types_Code_Example:
+.. _Ada_In_Practice_Abstract_Data_Types_Code_Example:
 
 .. code-block:: ada
 
@@ -225,7 +225,7 @@ former case. When it is strictly an implementation artifact, as in this
 case, it should be in the private part so that it's hidden from clients.
 
 The ADT idiom extends the information hiding applied by the
-:ref:`Groups of Related Program Units <Ada_Idioms_Groups_Of_Related_Program_Units>`
+:ref:`Groups of Related Program Units <Ada_In_Practice_Groups_Of_Related_Program_Units>`
 idiom to include the type's representation.
 
 The compile-time lack of visibility to the representation means that clients no
@@ -353,7 +353,7 @@ Cons
 
 There is more source code text required in an ADT package compared to the idiom
 in which the representation is not hidden (the
-:ref:`Groups of Related Program Units <Ada_Idioms_Groups_Of_Related_Program_Units>`).
+:ref:`Groups of Related Program Units <Ada_In_Practice_Groups_Of_Related_Program_Units>`).
 The bulk of the additional text is due to the functions and procedures
 required to provide the capabilities that the low-level representation-based
 syntax might have provided, i.e., the *constructor* and *selector/accessor*
@@ -366,10 +366,10 @@ Relationship With Other Idioms
 ------------------------------
 
 The package-oriented idioms described here and
-:ref:`previously <Ada_Idioms_Essential_Design_Idioms_For_Packages>`
+:ref:`previously <Ada_In_Practice_Essential_Design_Idioms_For_Packages>`
 are the foundational program composition idioms because packages are the
 primary structuring unit in Ada. That is especially true of the
-:ref:`Abstract Data Type <Ada_Idioms_Abstract_Data_Types>` idiom, which is the
+:ref:`Abstract Data Type <Ada_In_Practice_Abstract_Data_Types>` idiom, which is the
 primary type specification facility in Ada. We will
 describe additional package-oriented idioms,
 especially regarding hierarchical packages, but those kinds

content/courses/ada-idioms/chapters/component_access_to_rec_objs.rst → content/courses/ada-in-practice/chapters/component_access_to_rec_objs.rst

@@ -1,4 +1,4 @@
-.. _Ada_Idioms_Component_Access_To_Enclosing_Record_Objects:
+.. _Ada_In_Practice_Component_Access_To_Enclosing_Record_Objects:
 
 Providing Component Access to Enclosing Record Objects
 ======================================================
@@ -67,7 +67,7 @@ entities being represented in software. Representing these entities as multiple
 objects declared of a single type is by far the most reasonable approach.
 
 We assume the functional unit will be implemented as an
-:ref:`Abstract Data Type (ADT) <Ada_Idioms_Abstract_Data_Types>`. Strictly
+:ref:`Abstract Data Type (ADT) <Ada_In_Practice_Abstract_Data_Types>`. Strictly
 speaking, the ADT idiom is not required here, but that is the best approach for
 defining major types, for the good reasons given in that idiom entry. There's
 no reason not to use an ADT in this case so we will.
@@ -307,7 +307,7 @@ designs.
 
 Here's the resulting package declaration for the serial IO device ADT. Parts of
 the package are elided for simplicity (the full code is
-:ref:`at the end of this idiom entry <Ada_Idioms_Serial_IO_Complete_Example>`):
+:ref:`at the end of this idiom entry <Ada_In_Practice_Serial_IO_Complete_Example>`):
 
 .. code-block:: ada
 
@@ -395,7 +395,7 @@ Here is the client view of the ADT for the interrupt-driven implementation:
     end Serial_IO.Interrupt_Driven;
 
 The declaration of type :ada:`Serial_Port` uses
-:ref:`Interface Inheritance <Ada_Idioms_Inheritance_Idioms>` to extend
+:ref:`Interface Inheritance <Ada_In_Practice_Inheritance_Idioms>` to extend
 :ada:`Serial_IO.Device` with both visible and hidden components. The three
 visible extension components are the discriminants :ada:`Transceiver`,
 :ada:`IRQ`, and :ada:`IRQ_Priority`. :ada:`Transceiver` will designate the
@@ -552,11 +552,11 @@ Relationship With Other Idioms
 -------------------------------
 
 This idiom is useful when we have a record type enclosing a PO or task object.
-If the :ref:`Abstract Data Machine (ADM) <Ada_Idioms_Abstract_Data_Machines>`
+If the :ref:`Abstract Data Machine (ADM) <Ada_In_Practice_Abstract_Data_Machines>`
 would instead be appropriate, the necessary visibility can be achieved without
 requiring this implementation approach because there would be no enclosing record type.
 But as described in the ADM discussion, the
-:ref:`ADT approach <Ada_Idioms_Abstract_Data_Types>` is usually superior.
+:ref:`ADT approach <Ada_In_Practice_Abstract_Data_Types>` is usually superior.
 
 
 Notes
@@ -570,7 +570,7 @@ record component types. We could use the Hardware Abstraction Layer
 affect the idiom expression itself.
 
 
-.. _Ada_Idioms_Serial_IO_Complete_Example:
+.. _Ada_In_Practice_Serial_IO_Complete_Example:
 
 
 Full Source Code for Selected Units

content/courses/ada-idioms/chapters/constructor_functions_for_abstract_data_types.rst → content/courses/ada-in-practice/chapters/constructor_functions_for_abstract_data_types.rst

@@ -1,4 +1,4 @@
-.. _Ada_Idioms_Constructor_Functions_For_Abstract_Data_Types:
+.. _Ada_In_Practice_Constructor_Functions_For_Abstract_Data_Types:
 
 Constructor Functions For Abstract Data Types
 =============================================
@@ -25,7 +25,7 @@ existing parent type.
 
 This discussion assumes these tagged types are declared in packages designed
 using the
-:ref:`Abstract Data Type <Ada_Idioms_Abstract_Data_Types>` (ADT) idiom.
+:ref:`Abstract Data Type <Ada_In_Practice_Abstract_Data_Types>` (ADT) idiom.
 We strongly recommend the reader be comfortable with that idiom before
 proceeding.
 
@@ -98,7 +98,7 @@ their inheritance.
 The explanation and illustration for these rules first requires explanation of
 the word *abstract*. We mentioned above that the package enclosing the
 type will be designed with the
-:ref:`Abstract Data Type <Ada_Idioms_Abstract_Data_Types>` idiom. In that idiom
+:ref:`Abstract Data Type <Ada_In_Practice_Abstract_Data_Types>` idiom. In that idiom
 *abstract* means that the type represents an abstraction. (See that section for
 the details.)
 

content/courses/ada-idioms/chapters/controlling_obj_initialization_creation.rst → content/courses/ada-in-practice/chapters/controlling_obj_initialization_creation.rst

@@ -1,4 +1,4 @@
-.. _Ada_Idioms_Controlling_Object_Initialization_And_Creation:
+.. _Ada_In_Practice_Controlling_Object_Initialization_And_Creation:
 
 Controlling Object Initialization and Creation
 ==============================================
@@ -145,7 +145,7 @@ up to :ada:`Top`.
 And of course, the initial value might require client-specific information.
 
 Calling a
-:ref:`constructor function <Ada_Idioms_Constructor_Functions_For_Abstract_Data_Types>`
+:ref:`constructor function <Ada_In_Practice_Constructor_Functions_For_Abstract_Data_Types>`
 for the initial value would be the right approach in these cases, returning an
 object of the type. The function might even take an existing object as a
 parameter, creating a new object with only the necessary parts copied.
@@ -163,7 +163,7 @@ Preventing object creation is not typical but is not unknown. The
 is an example, in which a type is defined but corresponding object creation by
 clients is not intended. Instead, the abstraction implementation creates a
 single object of the type. The abstraction is a type, rather than an
-:ref:`ADM <Ada_Idioms_Abstract_Data_Machines>`, for the sake of potential
+:ref:`ADM <Ada_In_Practice_Abstract_Data_Machines>`, for the sake of potential
 extension via inheritance. We will illustrate this design pattern and implementation
 using a real-world hardware device.
 
@@ -185,7 +185,7 @@ are initialized before read.)
 
     Add link to SPARK ref for data initialization
 
-The :ref:`ADT idiom <Ada_Idioms_Abstract_Data_Types>` describes Ada *building
+The :ref:`ADT idiom <Ada_In_Practice_Abstract_Data_Types>` describes Ada *building
 blocks* that developers can use to compose types with semantics that we
 require. We can declare a type to be private, for example, so that the
 implementation is not compile-time visible to clients.
@@ -196,7 +196,7 @@ things) for client objects of the type. We can combine the two building blocks,
 creating a type that is both private and limited.
 
 Throughout this discussion we will assume that these designs are based on
-:ref:`Abstract Data Types <Ada_Idioms_Abstract_Data_Types>`, hence we assume
+:ref:`Abstract Data Types <Ada_In_Practice_Abstract_Data_Types>`, hence we assume
 the use of private types. That's a general, initial design assumption but in
 this case private types are required by the two idiom implementations. The types are
 not necessarily limited as well, but in one situation they will be limited too.
@@ -287,7 +287,7 @@ private.
 
 Unknown discriminants can be specified for various kinds of types, not only
 private types. See the
-:ref:`Notes section <Ada_Idioms_Controlling_Object_Initialization_And_Creation_Notes>`
+:ref:`Notes section <Ada_In_Practice_Controlling_Object_Initialization_And_Creation_Notes>`
 for the full list. That said, combining them with private type declarations, or
 private type extension declarations, is the most common usage when composing
 abstraction definitions. For example:
@@ -509,7 +509,7 @@ value. The compiler will not compile the code containing the declaration
 otherwise. The only constructor function provided is
 :ada:`Configured_Controller` so it is guaranteed to be called. (A later child
 package could add another
-:ref:`constructor function <Ada_Idioms_Constructor_Functions_For_Abstract_Data_Types>`.
+:ref:`constructor function <Ada_In_Practice_Constructor_Functions_For_Abstract_Data_Types>`.
 For that matter, we probably should have declared this one in a child package.
 In any case one of them is guaranteed to be called.)
 
@@ -967,7 +967,7 @@ class-wide type so that extensions could use it to allocate objects of their
 specific type, otherwise extensions in child packages would have no need for
 it. But that only saves the storage for an access object in the child packages,
 so we leave the declaration in the parent package body. See the
-:ref:`Programming by Extension idiom <Ada_Idioms_Programming_By_Extension>`
+:ref:`Programming by Extension idiom <Ada_In_Practice_Programming_By_Extension>`
 for a discussion of whether to declare an entity in the package private part or
 the package body.
 
@@ -1239,11 +1239,11 @@ None.
 Relationship With Other Idioms
 ------------------------------
 
-The :ref:`Abstract Data Type <Ada_Idioms_Abstract_Data_Types>` is assumed, in
+The :ref:`Abstract Data Type <Ada_In_Practice_Abstract_Data_Types>` is assumed, in
 the form of a private type.
 
 
-.. _Ada_Idioms_Controlling_Object_Initialization_And_Creation_Notes:
+.. _Ada_In_Practice_Controlling_Object_Initialization_And_Creation_Notes:
 
 Notes
 ----------------------------------------------------------

content/courses/ada-idioms/chapters/essential_idioms_for_packages.rst → content/courses/ada-in-practice/chapters/essential_idioms_for_packages.rst

@@ -1,4 +1,4 @@
-.. _Ada_Idioms_Essential_Design_Idioms_For_Packages:
+.. _Ada_In_Practice_Essential_Design_Idioms_For_Packages:
 
 Essential Design Idioms for Packages
 ====================================
@@ -57,7 +57,7 @@ package declarations will contain. But as you will see, what they can
 contain is a reflection of the degree of information hiding involved.
 
 
-.. _Ada_Idioms_Named_Collection_Of_Declarations:
+.. _Ada_In_Practice_Named_Collection_Of_Declarations:
 
 Named Collection of Declarations
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -116,7 +116,7 @@ idiom provides the way to declare it. Note also that global *constants*
 are less problematic than variables because they can't be changed.
 
 
-.. _Ada_Idioms_Groups_Of_Related_Program_Units:
+.. _Ada_In_Practice_Groups_Of_Related_Program_Units:
 
 Groups of Related Program Units
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -151,7 +151,7 @@ For example:
 In this example, :ada:`Vector` and :ada:`Matrix` are the types under
 consideration. The type :ada:`Real` might be declared here too, but it might be
 better declared in a
-:ref:`Named Collection of Declarations <Ada_Idioms_Named_Collection_Of_Declarations>`
+:ref:`Named Collection of Declarations <Ada_In_Practice_Named_Collection_Of_Declarations>`
 package referenced in a with_clause. In any case, this package declares types
 and subprograms that manipulate values of those types.