changes and delta

[gitmo/Moose.git] / lib / Moose / Manual / Types.pod

diff --git a/lib/Moose/Manual/Types.pod b/lib/Moose/Manual/Types.pod
index d4f5579..a032b18 100644 (file)
--- a/lib/Moose/Manual/Types.pod
+++ b/lib/Moose/Manual/Types.pod
@@ -39,13 +39,13 @@ The basic Moose type hierarchy looks like this
       Undef
       Defined
           Value
-              Num
-                Int
               Str
+                Num
+                    Int
                 ClassName
                 RoleName
           Ref
-              ScalarRef
+              ScalarRef[`a]
               ArrayRef[`a]
               HashRef[`a]
               CodeRef
@@ -57,9 +57,24 @@ The basic Moose type hierarchy looks like this
 In practice, the only difference between C<Any> and C<Item> is
 conceptual. C<Item> is used as the top-level type in the hierarchy.
 
-The rest of these types correspond to existing Perl concepts. For
-example, a C<Num> is anything that Perl thinks looks like a number, an
-C<Object> is a blessed reference, etc.
+The rest of these types correspond to existing Perl concepts.
+In particular:
+
+=over 4
+
+=item C<Bool> accepts C<1> for true, and any value that perl treats as false for false.
+
+=item C<Maybe[`a]> accepts either C<`a> or C<undef>.
+
+=item C<Num> accepts anything that perl thinks looks like a number (see L<Scalar::Util/looks_like_number>).
+
+=item C<ClassName> and C<RoleName> accept strings that are either the name of a class or the name of a role. The class/role must be loaded beforehand for this to succeed.
+
+=item C<FileHandle> accepts either an object of type L<IO::Handle> or a builtin perl filehandle (see L<Scalar::Util/openhandle>).
+
+=item C<Object> accepts any blessed reference.
+
+=back
 
 The types followed by "[`a]" can be parameterized. So instead of just
 plain C<ArrayRef> we can say that we want C<ArrayRef[Int]> instead. We
@@ -183,19 +198,18 @@ package, C<MyApp::Types>, which can be loaded by other classes in your
 application.
 
 Once you're doing this, you should almost certainly look at the
-L<MooseX::Types> extension which allows easy declaration of type libraries
-and can export your types as perl constants so that you can refer to them
-as just
+L<MooseX::Types> module. This module makes it easy to create a "type library"
+module, which can export your types as perl constants.
 
   has 'counter' => (is => 'rw', isa => PositiveInt);
 
-rather than needing to fully qualify them everywhere. It also allows
+This lets you use a short name rather than needing to fully qualify the name
+everywhere. It also allows you to write easily create parameterized types:
 
   has 'counts' => (is => 'ro', isa => HashRef[PositiveInt]);
 
-and similarly for the union and other syntax discussed below, which
-will compile time check your use of names and is generally more robust
-than the string type parsing for complex cases.
+This module will check your names at compile time, and is generally more
+robust than the string type parsing for complex cases.
 
 =head1 COERCION
 
@@ -412,16 +426,6 @@ define I<all> of your custom types in one module,
 C<MyApp::Types>. Second, load this module in all of your other
 modules.
 
-If you are still having load order problems, you can make use of the
-C<find_type_constraint> function exported by
-L<Moose::Util::TypeConstraints>:
-
-  class_type('MyApp::User')
-      unless find_type_constraint('MyApp::User');
-
-This sort of "find or create" logic is simple to write, and will let
-you work around load order issues.
-
 =head1 AUTHOR
 
 Dave Rolsky E<lt>autarch@urth.orgE<gt>