ToInstance no longer needs to subclass ToClass

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

diff --git a/lib/Moose/Manual/FAQ.pod b/lib/Moose/Manual/FAQ.pod
index 6bd6384..0864fd4 100644 (file)
--- a/lib/Moose/Manual/FAQ.pod
+++ b/lib/Moose/Manual/FAQ.pod
@@ -98,8 +98,8 @@ coercions, and C<lazy_build>, so subclassing is often not the ideal
 route.
 
 That said, if you really need to inherit from a non-Moose class, see
-L<Moose::Cookbook::Basics::Recipe12> for an example of how to do it,
-or take a look at L<MooseX::NonMoose> on CPAN.
+L<Moose::Cookbook::Basics::Recipe11> for an example of how to do it,
+or take a look at L<Moose::Manual::MooseX/"MooseX::NonMoose">.
 
 =head2 Accessors
 
@@ -281,18 +281,31 @@ C<NaturalLessThanTen> constraint check.
 
 Not yet. This option may come in a future release.
 
+=head3 My coercions stopped working with recent Moose, why did you break it?
+
+Moose 0.76 fixed a case where Coercions were being applied even if the original constraint passed. This has caused some edge cases to fail where people were doing something like
+
+    subtype Address => as 'Str';
+    coerce Address => from Str => via { get_address($_) };
+
+Which is not what they intended. The Type Constraint C<Address> is too loose in this case, it is saying that all Strings are Addresses, which is obviously not the case. The solution is to provide a where clause that properly restricts the Type Constraint.
+
+    subtype Address => as Str => where { looks_like_address($_) };
+
+This will allow the coercion to apply only to strings that fail to look like an Address.
+
 =head2 Roles
 
 =head3 Why is BUILD not called for my composed roles?
 
-BUILD is never called in composed roles. The primary reason is that
+C<BUILD> is never called in composed roles. The primary reason is that
 roles are B<not> order sensitive. Roles are composed in such a way
 that the order of composition does not matter (for information on the
 deeper theory of this read the original traits papers here
 L<http://www.iam.unibe.ch/~scg/Research/Traits/>).
 
 Because roles are essentially unordered, it would be impossible to
-determine the order in which to execute the BUILD methods.
+determine the order in which to execute the C<BUILD> methods.
 
 As for alternate solutions, there are a couple.
 
@@ -379,7 +392,7 @@ Stevan Little E<lt>stevan@iinteractive.comE<gt>
 
 =head1 COPYRIGHT AND LICENSE
 
-Copyright 2006-2009 by Infinity Interactive, Inc.
+Copyright 2006-2010 by Infinity Interactive, Inc.
 
 L<http://www.iinteractive.com>