don't reject win32 filenames (Yappo)
[gitmo/Moose.git] / lib / Moose / Intro.pod
index df465de..57472de 100644 (file)
@@ -14,7 +14,7 @@ language, and you don't care how they are implemented.
 
 Moose aims to do the same thing for Perl 5 OO. We can't actually
 create new keywords, but we do offer "sugar" that looks a lot like
-them. More importantly, with Moose, you I<declaritively define> your
+them. More importantly, with Moose, you I<declaratively define> your
 class, without needing to know about blessed hashrefs, accessor
 methods, and so on.
 
@@ -104,14 +104,14 @@ your classes!>
 
 Moose will provide one for you. It will accept a hash or hash
 reference of named parameters matching your attributes. This is just
-another way in which Moose keeps your from worrying I<how> classes are
+another way in which Moose keeps you from worrying I<how> classes are
 implemented. Simply define a class and you're ready to start creating
 objects!
 
 =head1 MOOSE CONCEPTS (VS "OLD SCHOOL" Perl)
 
 In the past, you may not have thought too much about the difference
-between packages and classes, attributes and methods, constructors vs
+between packages and classes, attributes and methods, constructors and
 methods, etc. Part of what the MOP provides is well-defined
 introspection features for each of those things, and in turn Moose
 provides I<distinct> sugar for each of them. Moose also introduces
@@ -132,19 +132,20 @@ A class I<has> zero or more B<attributes>.
 
 A class I<has> zero or more B<methods>.
 
-A class I<may have> one or more superclasses (aka parent classes). A
+A class I<has> zero or more superclasses (aka parent classes). A
 class inherits from its superclass(es).
 
-A class may I<have> B<method modifiers>. These modifiers can apply to
-its own methods or methods that are inherited from its ancestors.
+A class I<has> zero or more B<method modifiers>. These modifiers can
+apply to its own methods or methods that are inherited from its
+ancestors.
 
-A class may I<do> one or more B<roles>.
+A class may I<do> zero or more B<roles>.
 
 A class I<has> a B<constructor> and a B<destructor>. These are
 provided for you "for free" by Moose.
 
 The B<constructor> accepts named parameters corresponding to the
-class's attributes and uses them to initialize an B<object instances>.
+class's attributes and uses them to initialize an B<object instance>.
 
 A class I<has> a B<metaclass>, which in turn has B<meta-attributes>,
 B<meta-methods>, and B<meta-roles>. This metaclass I<describes> the
@@ -182,7 +183,7 @@ It is best to think of Moose attributes as "properties" of the
 I<opaque> B<object instance>. These properties are accessed through
 well-defined accessor methods.
 
-An attribute is usually analagous to specific feature of something in
+An attribute is usually analogous to a specific feature of something in
 the class's category. For example, People have first and last
 names. Users have passwords and last login datetimes.
 
@@ -204,7 +205,7 @@ example, a User can login.
 =head2 Roles
 
 A role is something that a class I<does>. For example, a Machine class
-might do the Breakable role, and a so could a Bone class. A role is
+might do the Breakable role, and so could a Bone class. A role is
 used to define some concept that cuts across multiple unrelated
 classes, like "breakability", or "has a color".
 
@@ -222,7 +223,7 @@ method says "to use this Role you must implement this method".
 Roles are I<composed> into classes (or other roles). When a role is
 composed into a class, its attributes and methods are "flattened" into
 the class. Roles I<do not> show up in the inheritance hierarchy. When
-a role is composed, it's attributes and methods appear as if they were
+a role is composed, its attributes and methods appear as if they were
 defined I<in the consuming class>.
 
 Role are somewhat like mixins or interfaces in other OO languages.
@@ -320,7 +321,7 @@ example, one specific Person or User. An instance is created by the
 class's B<constructor>.
 
 An instance has values for its attributes. For example, a specific
-person has a first and last name,
+person has a first and last name.
 
 In old school Perl 5, this is often a blessed hash reference. With
 Moose, you should never need to know what your object instance
@@ -342,7 +343,7 @@ With Moose, you get well-defined declaration and introspection.
 Hand-written accessor methods, symbol table hackery, or a helper
 module like C<Class::Accessor>.
 
-With Moose, these are declaritively defined, and distinct from
+With Moose, these are declaratively defined, and distinct from
 methods.
 
 =item * Method
@@ -432,7 +433,7 @@ L<Moose::Meta::TypeConstraint>, L<Moose::Meta::Instance>, and so on.
 
 =head1 BUT I NEED TO DO IT MY WAY!
 
-One of the great things about Moose, is that if you dig down and find
+One of the great things about Moose is that if you dig down and find
 that it does something the "wrong way", you can change it by extending
 a metaclass. For example, you can have arrayref based objects, you can
 make your constructors strict (no unknown params allowed!), you can
@@ -441,7 +442,7 @@ Singleton, and much, much more.
 
 Many of these extensions require surprisingly small amounts of code,
 and once you've done it once, you'll never have to hand-code "your way
-of doing things" again. Instead you ll just load your favorite
+of doing things" again. Instead you'll just load your favorite
 extensions.
 
   package MyWay::User;
@@ -530,7 +531,7 @@ on and read the Meta and Extending recipes, but those are mostly there
 for people who want to be Moose wizards and change how Moose works.
 
 If you want to see how Moose would translate directly old school Perl
-5 OO code, check out the L<Moose::Unsweetened>.
+5 OO code, check out L<Moose::Unsweetened>.
 
 =head1 AUTHOR