Typographical etc. corrections to objects.pod

Author: paultcochrane

lib/Language/objects.pod

@@ -14,7 +14,7 @@ Native types are used for low-level types (like C<uint64>). They do not
 have the same capabilities as objects, though if you call methods on them,
 they are I<boxed> into normal objects.
 
-Everything that you can store in a variable is either a native value, or an
+Everything that you can store in a variable is either a native value or an
 object. That includes literals, types (type objects), code and containers.
 
 =head1 Using Objects
@@ -36,7 +36,7 @@ my $formatted-text = "Fourscore and seven years ago...".L<indent>B<(8)>;
 
 C<$formatted-text> now contains the above text, but indented 8 spaces.
 
-Multiple arguments just require a comma between them:
+Multiple arguments simply require a comma between them:
 
 =for code :allow<B L>
 my @words = "Abe", "Lincoln";
@@ -50,7 +50,7 @@ say @words.L<join>: '--';
 # Abe--Lincoln--said--Fourscore--and--seven--years--ago
 
 Since you have to put a C<:> after the method if you want to pass arguments
-without parenthesis, a method call without a colon or parens is unambiguously
+without parentheses, a method call without a colon or parens is unambiguously
 a method call without an argument list:
 
     $computation-result.say;
@@ -75,7 +75,7 @@ of the type hierarchy. In other words, all objects are derived from C<Mu>.
 
 =head2 Type Objects
 
-Types themselves are objects, and you can get the I<type object> simply
+Types themselves are objects and you can get the I<type object> simply
 by writing its name:
 
     my $int-type-obj = Int;
@@ -149,7 +149,7 @@ are typically declared using the C<has> declarator and using the C<!> twigil.
 
 While there is no such thing as a public (or even protected) attribute, there
 is a way to have accessor methods generated automatically: replace the C<!>
-twigil with the C<.> twigil (the C<.> should remind you of method call).
+twigil with the C<.> twigil (the C<.> should remind you of a method call).
 
     class Journey {
         has $.origin;
@@ -169,7 +169,7 @@ the attribute, add the C<rw> trait:
     }
 
 Now, after a C<Journey> object is created, its C<.origin>,
-C<.destination>, and C<.notes> will all be accessible from outside of the
+C<.destination>, and C<.notes> will all be accessible from outside the
 class, but only C<.notes> can be modified.
 
 Since classes inherit a default constructor from C<Mu> and we have requested
@@ -196,7 +196,7 @@ accessor method.
 
 =head2 Methods
 
-Methods are declared with the C<method> keyword inside of a class body.
+Methods are declared with the C<method> keyword inside a class body.
 
     =begin code :allow<B L>
     class Journey {
@@ -221,29 +221,29 @@ Methods are declared with the C<method> keyword inside of a class body.
     =end code
 
 A method can have a signature, just like a subroutine. Attributes can be used
-in methods, and can always be used with the C<!> twigil, even if they are
+in methods and can always be used with the C<!> twigil, even if they are
 declared with the C<.> twigil. This is because really, the C<.> twigil declares
-an attribute with the C<!> twigil in its place, and then additionally generates
+an attribute with the C<!> twigil in its place and then additionally generates
 an accessor method.
 
 There is a subtle but important difference between using, say, C<$!origin> and
 C<$.origin> in the method C<describe>. The first is always a simple lookup of
 the attribute. It is cheap, and you know that it is the attribute declared in
-this class. The latter is really a method call, and thus it may be overridden
+this class. The latter is really a method call and thus it may be overridden
 in a subclass. Only use C<$.origin> if you explicitly want to allow overriding.
 
 =head2 self
 
-Inside a method, the term C<self> is available, which is bound to invocant, i.e.
+Inside a method, the term C<self> is available, which is bound to the invocant, i.e.
 the object that the method was called on. C<self> can be used to call further
-methods on the invocant, for example. Within methods, something like
+methods on the invocant. Within methods, something like
 C<$.origin> is the same thing as C<self.origin>.
 
 =head2 Private Methods
 
-Methods for internal usage inside the class that cannot be called from
-anywhere else are introduced with an exclamation mark C<!> before the method
-name, and are called with the exclamation mark instead of the dot:
+Methods strictly for use inside the class and that are not to be called from
+anywhere else are declared with an exclamation mark C<!> before the method
+name. They are called with an exclamation mark instead of a dot:
 
     method !do-something-private($x) {
         ...
@@ -258,7 +258,7 @@ Private methods are not inherited to subclasses.
 
 =head2 Submethods
 
-A submethod is public method that is not inherited to subclasses. The name
+A submethod is a public method that is not inherited to subclasses. The name
 stems from the fact that they are semantically similar to subroutines.
 
 Submethods are useful for object construction and destruction tasks, as well
@@ -275,12 +275,11 @@ Classes can have I<parent classes>.
 class Child B<L<is> Parent1 is Parent2> { }
 
 If a method is called on the child class, and the child class does not
-provide that method, the parent classes' method of that name is invoked instead,
+provide that method, the method of that name in one of the parent classes is invoked instead,
 if it exists. The order in which parent classes are consulted is called the
 I<method resolution order> (MRO). Perl 6 uses the
 L<C3 method resolution order|https://en.wikipedia.org/wiki/C3_linearization>.
-You can ask a type for its MRO through a call to its metaclass:
-
+You can ask a type for its MRO through a call to its meta class:
 
 =for code :allow<B L>
 say ParcelB<.^L<mro>>;    # Parcel() Cool() Any() Mu()
@@ -289,7 +288,7 @@ If a class does not specify a parent class, L<Any> is assumed by default. All
 classes directly or indirectly derive from L<Mu>, the root of the type
 hierarchy.
 
-All calls to public method are "virtual" in the C++ sense, which means that
+All calls to public methods are "virtual" in the C++ sense, which means that
 the actual type of an object determines which method to call, not the declared
 type:
 
@@ -317,7 +316,7 @@ This produces the output:
 
 =head2 Object Construction
 
-Objects are generally created through methods calls, either on the type object
+Objects are generally created through method calls, either on the type object
 or on another object of the same type.
 
 Class L<Mu> provides a constructor method called L<new>, which takes named
@@ -350,10 +349,10 @@ This outputs:
     x: 5
     y: 10
 
-Mu.new calls method L<bless> on its invocant, passing along all the named
-arguments. C<bless> creates the new object, and then calls method C<BUILDALL>
+C<Mu.new> calls method L<bless> on its invocant, passing all the named
+arguments. C<bless> creates the new object and then calls method C<BUILDALL>
 on it. C<BUILDALL> walks all subclasses in reverse method resolution order
-(i.e. from L<Mu> to most derived classes), and in each class checks for
+(i.e. from L<Mu> to most derived classes) and in each class checks for
 existence of a method named C<BUILD>. If it exists, it is called, again
 passing all named arguments from method C<new> to it. If not, the public
 attributes from this class are initialized from named arguments of the same
@@ -362,7 +361,7 @@ initialized the attribute, default values are applied (the C<2 * $!x> in the
 example above).
 
 Due to the nature of the default behavior of C<BUILDALL> and custom C<BUILD>
-submethods, you named arguments to the constructor C<new> derived from C<Mu>
+submethods, named arguments to the constructor C<new> derived from C<Mu>
 can correspond directly to public attributes of any of the classes in the
 method resolution order, or to any named parameter to any C<BUILD> submethod.
 
@@ -388,8 +387,8 @@ time. They can also be used for creating aliases for attribute initialization:
     =end code
 
 Since passing arguments to a routine binds the arguments to the parameters,
-a separate binding step is unnecessary if the attribute is used as parameter.
-So the example above could also have been written as:
+a separate binding step is unnecessary if the attribute is used as a parameter.
+Hence the example above could also have been written as:
 
     =for code :allow<B L>
     submethod BUILD(:encoding(:$B<!>enc), :$B<!>data) {
@@ -420,9 +419,9 @@ use C<CREATE> to fiddle around with low-level workings.
 
 Roles are in some ways similar to classes, in that they are a collection of
 attributes and methods. They differ in that roles are also meant for
-describing only parts of an object's behavior, and in how roles are applied to
+describing only parts of an object's behavior and in how roles are applied to
 classes. Or to phrase it differently, classes are meant for managing
-instances, and roles are meant for managing behavior and code reuse.
+instances and roles are meant for managing behavior and code reuse.
 
     =begin code :allow<B L>
     role Serializable {
@@ -482,8 +481,8 @@ and a class C<Automobile>, for things that you can drive.
     my $t = Taurus.new;
     $t.steer; # Castrates $t
 
-With this set-up, your poor customers will find themselves unable to
-turn their Taurus, and you won't be able to make more of your product!
+With this setup, your poor customers will find themselves unable to
+turn their Taurus and you won't be able to make more of your product!
 In this case, it may have been better to use roles:
 
     role Bull-Like {
@@ -508,7 +507,7 @@ This code will die with something like:
     Method 'steer' must be resolved by class Taurus because it exists in
     multiple roles (Steerable, Bull-Like)
 
-This check will save you and your customers a lot of headaches, and you
+This check will save you and your customers a lot of headaches and you
 can simply define your class instead as:
 
     class Taurus does Bull-Like does Steerable {
@@ -548,7 +547,7 @@ This allows you to create roles that act as abstract interfaces.
     =begin code :allow<B L>
     role AbstractSerializable {
         method serialize() { B<L<...>> }  # literal ... here marks the
-                                    # method as a stub
+                                          # method as a stub
     }
 
     # the following is a compile time error, for example
@@ -580,7 +579,7 @@ objects; those objects are called I<meta objects>. Meta objects are, like
 ordinary objects, instances of classes, in this case we call them I<meta
 classes>.
 
-For each object or class, you can get the meta object by calling C<.HOW> on
+For each object or class you can get the meta object by calling C<.HOW> on
 it. Note that although this looks like a method call, it is actually
 special-cased in the compiler, so it is more like a macro.
 
@@ -599,7 +598,7 @@ C<Perl6::Metamodel::ClassHOW>.
 
 But of course the meta model does much more for you. For example it allows you
 to introspect objects and classes. The calling convention for methods on meta
-objects is to call the method on the meta object, and pass in the object of
+objects is to call the method on the meta object and pass in the object of
 interest as first argument to the object. So to get the name of the class of
 an object, you could write:
 
@@ -621,7 +620,7 @@ To get rid of using the same object twice, there is a shortcut:
     say 1.HOW.name(1);                  # Int
 
 See L<Metamodel::ClassHOW|/type/Metamodel::ClassHOW> for documentation of
-the meta class of C<class>, and also the L<general documentation on the meta
+the meta class of C<class> and also the L<general documentation on the meta
 object protocol|/language/mop>.
 
 =end pod