additional typo fixes

Author: QuentinOchem

features/rfc-oop-aggregates-and-assignments.rst

@@ -22,31 +22,31 @@ replace initialization. But the consequence is that there's no way to ensure
 that a given sequence of statement is putting an object in a consistent state
 at creation time (unlike traditional constructors).
 
-Second Adjust perform a post-copy update to a type. This causes a double issue,
+Second, Adjust perform a post-copy update to a type. This causes a double issue,
 first in terms of performance, as assignment may not need all components to be
 modified. But this also limits the control over assignment logic, as the user
 has no way to know what was the initial state of the object or what object
 was initially copied from.
 
 Third, Ada allows partial assignment of objects through parent views. To
 some respect, this is also an issue, as the resulting object may be inconsistent,
-with only part updated, and potentially now way in Adjust to understand which
+with only part updated, and potentially no way in Adjust to understand which
 part was changed and which part was not.
 
 A related issue is the so called "Aggregate by extension" where a root object
 is copied into a child one with specific values provided by the aggregate,
 again here with no control over the consistency of values (not even in Adjust
-in the case of initialiation).
+in the case of initialization).
 
 To solve these issues, we propose to introduce a two step object update
 mechanism through a value duplication ('Clone) and post update adjustment
 ('Adjust).
 
 Note that this extra complexity is driven from the desire to support natively
-Ada constructions (aggregates, partial copie, etc) and improve compatibility
+Ada constructs (aggregates, partial copies, etc) and improve compatibility
 between classes and tagged types. Users can leverage default implementation if
 such level of control is unecessary. Some language extension may also allow
-to forbig aggregates and partial update on specific types (although this
+to forbid aggregates and partial update on specific types (although this
 introduces complexities in generics that now need to specify wether these
 restricted types are allowed or not).
 
@@ -92,7 +92,7 @@ calls clone operation of all the components one by one. The compiler is free to
 optimize to bitwise copies if clone operations are not user-defined.
 
 Calls to 'Clone are statically resolved when used on definite views, and
-dynamcially resolved on 'Class wide type. This is arguably a departure from the
+dynamically resolved on 'Class wide type. This is arguably a departure from the
 "all calls are dispatching" requirement from other aspects of the OOP design,
 but is required to allow partial copies of objects which are done today in
 various places Ada.
@@ -108,7 +108,7 @@ different from the legacy Ada Adjust primitive in that it has an argument
 refering to the initial value. Note that the From parameter of adjust is
 always typed after the root type of the tagged record hierarchy - indeed, the source
 object may be higher up in the derivation chain in the case of partial
-copy. This value value is provided for reference but is not expected to be
+copy. This value is provided for reference but is not expected to be
 modified.
 
 .. code-block:: ada
@@ -214,7 +214,7 @@ Partial Copy Assignments
 ------------------------
 
 Ada dynamically checks for tags compatibility in the context of two 'Class
-types, which can only be assigned if there are of the same type. However, if the
+types, which can only be assigned if they are of the same type. However, if the
 views are definite, the assignment is partial. For example:
 
 .. code-block:: ada
@@ -348,7 +348,7 @@ A few notes on the above sequences:
   destructor, adjust and clone attributes is somewhat heavy, as the aggregate
   needs to be fully initialized before cloned, then reclaimed. It's important
   to have self consistency here. However, developer may prefer to reserve
-  aggregate notation for types that do not require these constructions, and
+  aggregate notation for types that do not require these constructs, and
   the compiler should optimize the sequencing in these cases.
 
 Aggregate Assignments with Extension Copies
@@ -616,7 +616,7 @@ We looked at various ways to remove the need of temporaries, for example by
 introducing special constructors taking aggregate values as paramters. However,
 this quickly leads to the need of creating a lot of extra attributes for all
 situations. In light of the added complexity, and the fact that we can
-provide means to acheive desired optimization when needed, it didn't look like
+provide means to achieve desired optimization when needed, it didn't look like
 the right trade-off.
 
 Drawbacks

features/rfc-oop-destructors.rst

@@ -76,7 +76,8 @@ The destruction sequence works in the following way:
 
 - If a type has an explicit destructor, it is first called.
 - If a type has components hierarchy, wether or not it has an explicit
-  destructor, the destructor sequence is called on each components.
+  destructor, the destructor sequence is called on each components, in
+  reverse order of construction.
 - If a type is in a tagged hierarchy, wether or not it has an explicit
   destructor, the parent destructor sequence is called.
 

features/rfc-oop-dispatching.rst

@@ -132,7 +132,7 @@ does not support multi-parameter dispatching.
 Dispactching on Returned Types
 ------------------------------
 
-A tag indeterminate disatching call is illegal (as it is the case today). For
+A tag indeterminate dispatching call is illegal (as it is the case today). For
 example:
 
 .. code-block:: ada
@@ -198,7 +198,7 @@ a scope where Default_Dispatching_Calls is On. For example:
       [... some code ...]
 
          A_D.all (Obj); -- This dispatches
-         A_ND.all (Obj); -- This doesn't dispatches
+         A_ND.all (Obj); -- This doesn't dispatch
 
       [... some code ...]
 
@@ -221,7 +221,7 @@ Rationale and alternatives
 It is a potential vulnerability not to call an overriden primitive. This may
 lead to an object to be in an state that has not been anticipated, in particular
 when the role of the overriden primitive is to keep the state of the derived
-object consistant. It's also commonly the case in most OOP languages that
+object consistent. It's also commonly the case in most OOP languages that
 dispatching is the default expected behavior and non dispatching the exception.
 
 This also fixes a common confusion in Ada, where the dispatching parameter of A

features/rfc-oop-primitives.rst

@@ -14,13 +14,13 @@ Guide-level explanation
 Class objects
 -------------
 
-A new type of type is introduce, the `class` type. This type operates similarly
+A new type of type is introduced, the `class` type. This type operates similarly
 to tagged type (there are even situations where it can be derived from one)
 with a number of differences:
 
 - It's always a by-constructor type
 - It cannot have coextensions (so no access-type discriminants)
-- It primitives must follow the rules of First_Controlling_Parameter
+- Its primitives must follow the rules of First_Controlling_Parameter
 - It always follows the rules of Default_Dispatching_Calls
 - Primitives need to be declared within its scope - operations declared outside
   of its scope are not primitives.
@@ -55,7 +55,7 @@ bodies. The following demonstrates the above:
          procedure Prim (Self : in out R; V : Integer) is
          begin
             Self.F := V;
-         end record;
+         end Prim;
 
          procedure Prim_2 (Self : in out R; V : Integer) is
          begin
@@ -72,7 +72,7 @@ bodies. The following demonstrates the above:
 
 Primitives declared within a type can only be called via prefix notation. When
 primitives are declared in a scope, there can no longer be primitives declared
-ouside of the scope, such declarations are non-primitives.
+outside of the scope, such declarations are non-primitives.
 
 Scoped primitives can be referred to with their fully qualified notation (for
 example, when using access to suprograms or renamings), for example here as
@@ -129,8 +129,8 @@ Operators can be declared as primitives:
       end record;
 
       type T2 is new T1 with class record
-         procedure "=" (Left : T2; Right : T1);
-         function "+" (Left : T2, Right : T1) return T1;
+         function "=" (Left : T2; Right : T1) return Boolean;
+         function "+" (Left : T2; Right : T1) return T1;
       end record;
    end P;
 
@@ -165,7 +165,7 @@ It is possible to also scope primitives in regular records:
 
    end P;
 
-Declaring primities outside of regular records is still possible. It's not
+Declaring primitives outside of regular records is still possible. It's not
 possible to declare primitives within a regular tagged record.
 
 Non-primitive scoped operations
@@ -221,7 +221,7 @@ of the scope of a class record cannot be called though prefix notation. Notably:
 Discriminants
 -------------
 
-Disciminants of class record need to be repeated on both public and private
+Discriminants of class record need to be repeated on both public and private
 declaration views, but not their body view (similar to e.g. protected types).
 E.g:
 

features/rfc-oop-super.rst

@@ -34,7 +34,7 @@ can be used to make non dispatching calls. For example:
    end Call;
 
 Note that `'Super` being used to make non dispatching calls to primitives using
-the parent view, it is only available is said view is of a derived type (there'S
+the parent view, it is only available if said view is of a derived type (there'S
 no primitive to call otherwise).
 
 Reference-level explanation