This module was designed to be as unintrusive as possible. Many of its
features are accessible without B<any> change to your existing
-code. It is meant to be a compliment to your existing code and not an
+code. It is meant to be a complement to your existing code and not an
intrusion on your code base. Unlike many other B<Class::> modules,
this module B<does not> require you subclass it, or even that you
C<use> it in within your module's package.
-The only features which requires additions to your code are the
+The only features which require additions to your code are the
attribute handling and instance construction features, and these are
both completely optional features. The only reason for this is because
Perl 5's object system does not actually have these features built
class's ancestors.
Downward metaclass compatibility means that the metaclasses of a
-given class's ancestors are all either the same as (or a subclass
-of) that metaclass.
+given class's ancestors are all the same as (or a subclass of) that
+metaclass.
Here is a diagram showing a set of two classes (C<A> and C<B>) and
two metaclasses (C<Meta::A> and C<Meta::B>) which have correct
problem, and one which can only occur if you are doing deep metaclass
programming. So in other words, don't worry about it.
-Note that if you're using L<Moose> we encourage you to I<not> use
+Note that if you're using L<Moose> we encourage you to I<not> use the
L<metaclass> pragma, and instead use L<Moose::Util::MetaRole> to apply
roles to a class's metaclasses. This topic is covered at length in
various L<Moose::Cookbook> recipes.
=head2 Metaclass cache functions
-Class::MOP holds a cache of metaclasses. The following are functions
+C<Class::MOP> holds a cache of metaclasses. The following are functions
(B<not methods>) which can be used to access that cache. It is not
recommended that you mess with these. Bad things could happen, but if
you are brave and willing to risk it: go for it!