expand on the descriptions for the built-in type constraints

diff --git a/lib/Moose/Manual/Types.pod b/lib/Moose/Manual/Types.pod
index d4f5579..e8313c3 100644 (file)
--- a/lib/Moose/Manual/Types.pod
+++ b/lib/Moose/Manual/Types.pod
@@ -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 a 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