1 package Moose::Manual::Delta;
3 # ABSTRACT: Important Changes in Moose
11 This documents any important or noteworthy changes in Moose, with a
12 focus on things that affect backwards compatibility. This does duplicate data
13 from the F<Changes> file, but aims to provide more details and when possible
16 Besides helping keep up with changes, you can also use this document
17 for finding the lowest version of Moose that supported a given
18 feature. If you encounter a problem and have a solution but don't see
19 it documented here, or think we missed an important feature, please
26 =item All the Cookbook recipes have been renamed
28 We've given them all descriptive names, rather than numbers. This makes it
29 easier to talk about them, and eliminates the need to renumber recipes in
30 order to reorder them or delete one.
32 =item Applying the same role more than once is a no-op
34 In previous versions of Moose, applying the same role more than once actually
35 went through the whole role application algorithm each time. This was mostly a
36 no-op, but it had a few side effects. First, if you looked at the role objects
37 for a metaclass (or role), you'd see the same role object more than
38 once. Second, method modifiers would be applied multiple times.
40 Now, if you try to apply the same role twice, it is a real no-op. Note that
41 "same" is based on the Moose::Meta::Role object itself, not the role's
42 name. This means you can apply multiple instances of a
43 L<MooseX::Role::Parameterized> role if you want.
51 =item The parent of a union type is its components' nearest common ancestor
53 Previously, union types considered all of their component types their parent
54 types. This was incorrect because parent types are defined as types that must
55 be satisfied in order for the child type to be satisfied, but in a union,
56 validating as any parent type will validate against the entire union. This has
57 been changed to find the nearest common ancestor for all of its components. For
58 example, a union of "Int|ArrayRef[Int]" now has a parent of "Defined".
60 =item Union types consider all members in the C<is_subtype_of> and C<is_a_type_of> methods
62 Previously, a union type would report itself as being of a subtype of a type if
63 I<any> of its member types were subtypes of that type. This was incorrect
64 because any value that passes a subtype constraint must also pass a parent
65 constraint. This has changed so that I<all> of its member types must be a
66 subtype of the specified type.
68 =item Enum types now work with just one value
70 Previously, an C<enum> type needed to have two or more values. Nobody knew
73 =item Methods defined in UNIVERSAL now appear in the MOP
75 Any method introspection methods that look at methods from parent classes now
76 find methods defined in UNIVERSAL. This includes methods like C<<
77 $class->get_all_methods >> and C<< $class->find_method_by_name >>.
79 This also means that you can now apply method modifiers to these methods.
81 =item Hand-optimized type constraint code causes a deprecation warning
83 If you provide an optimized sub ref for a type constraint, this now causes a
84 deprecation warning. Typically, this comes from passing an C<optimize_as>
85 parameter to C<subtype>, but it could also happen if you create a
86 L<Moose::Meta::TypeConstraint> object directly.
88 Use the inlining feature (C<inline_as>) added in 2.0100 instead.
90 =item C<Class::Load::load_class> and C<is_class_loaded> have been removed
92 The C<Class::MOP::load_class> and C<Class::MOP::is_class_loaded> subroutines
93 are no longer documented, and will cause a deprecation warning in the
94 future. Moose now uses L<Class::Load> to provide this functionality, and you
103 =item Array and Hash native traits provide a C<shallow_clone> method
105 The Array and Hash native traits now provide a "shallow_clone" method, which
106 will return a reference to a new container with the same contents as the
107 attribute's reference.
115 =item Hand-optimized type constraint code is deprecated in favor of inlining
117 Moose allows you to provide a hand-optimized version of a type constraint's
118 subroutine reference. This version allows type constraints to generate inline
119 code, and you should use this inlining instead of providing a hand-optimized
120 subroutine reference.
122 This affects the C<optimize_as> sub exported by
123 L<Moose::Util::TypeConstraints>. Use C<inline_as> instead.
125 This will start warning in the 2.0300 release.
133 =item More useful type constraint error messages
135 If you have L<Devel::PartialDump> version 0.14 or higher installed, Moose's
136 type constraint error messages will use it to display the invalid value, rather
137 than just displaying it directly. This will generally be much more useful. For
138 instance, instead of this:
140 Attribute (foo) does not pass the type constraint because: Validation failed for 'ArrayRef[Int]' with value ARRAY(0x275eed8)
142 the error message will instead look like
144 Attribute (foo) does not pass the type constraint because: Validation failed for 'ArrayRef[Int]' with value [ "a" ]
146 Note that L<Devel::PartialDump> can't be made a direct dependency at the
147 moment, because it uses Moose itself, but we're considering options to make
156 =item Roles have their own default attribute metaclass
158 Previously, when a role was applied to a class, it would use the attribute
159 metaclass defined in the class when copying over the attributes in the role.
160 This was wrong, because for instance, using L<MooseX::FollowPBP> in the class
161 would end up renaming all of the accessors generated by the role, some of which
162 may be being called in the role, causing it to break. Roles now keep track of
163 their own attribute metaclass to use by default when being applied to a class
164 (defaulting to Moose::Meta::Attribute). This is modifiable using
165 L<Moose::Util::MetaRole> by passing the C<applied_attribute> key to the
166 C<role_metaroles> option, as in:
168 Moose::Util::MetaRole::apply_metaroles(
171 attribute => ['My::Meta::Role::Attribute'],
174 applied_attribute => ['My::Meta::Role::Attribute'],
178 =item Class::MOP has been folded into the Moose dist
180 Moose and Class::MOP are tightly related enough that they have always had to be
181 kept pretty closely in step in terms of versions. Making them into a single
182 dist should simplify the upgrade process for users, as it should no longer be
183 possible to upgrade one without the other and potentially cause issues. No
184 functionality has changed, and this should be entirely transparent.
186 =item Moose's conflict checking is more robust and useful
188 There are two parts to this. The most useful one right now is that Moose will
189 ship with a C<moose-outdated> script, which can be run at any point to list the
190 modules which are installed that conflict with the installed version of Moose.
191 After upgrading Moose, running C<moose-outdated | cpanm> should be sufficient
192 to ensure that all of the Moose extensions you use will continue to work.
194 The other part is that Moose's C<META.json> file will also specify the
195 conflicts under the C<x_conflicts> key. We are working with the Perl tool chain
196 developers to try to get conflicts support added to CPAN clients, and if/when
197 that happens, the metadata already exists, and so the conflict checking will
200 =item Most deprecated APIs/features are slated for removal in Moose 2.0200
202 Most of the deprecated APIs and features in Moose will start throwing an error
203 in Moose 2.0200. Some of the features will go away entirely, and some will
204 simply throw an error.
206 The things on the chopping block are:
210 =item * Old public methods in Class::MOP and Moose
212 This includes things like C<< Class::MOP::Class->get_attribute_map >>, C<<
213 Class::MOP::Class->construct_instance >>, and many others. These were
214 deprecated in L<Class::MOP> 0.80_01, released on April 5, 2009.
216 These methods will be removed entirely in Moose 2.0200.
218 =item * Old public functions in Class::MOP
220 This include C<Class::MOP::subname>, C<Class::MOP::in_global_destruction>, and
221 the C<Class::MOP::HAS_ISAREV> constant. The first two were deprecated in 0.84,
222 and the last in 0.80. Class::MOP 0.84 was released on May 12, 2009.
224 These functions will be removed entirely in Moose 2.0200.
226 =item * The C<alias> and C<excludes> option for role composition
228 These were renamed to C<-alias> and C<-excludes> in Moose 0.89, released on
231 Passing these will throw an error in Moose 2.0200.
233 =item * The old L<Moose::Util::MetaRole> API
235 This include the C<apply_metaclass_roles()> function, as well as passing the
236 C<for_class> or any key ending in C<_roles> to C<apply_metaroles()>. This was
237 deprecated in Moose 0.93_01, released on January 4, 2010.
239 These will all throw an error in Moose 2.0200.
241 =item * Passing plain lists to C<type()> or C<subtype()>
243 The old API for these functions allowed you to pass a plain list of parameter,
244 rather than a list of hash references (which is what C<as()>, C<where>,
245 etc. return). This was deprecated in Moose 0.71_01, released on February 22,
248 This will throw an error in Moose 2.0200.
250 =item * The Role subtype
252 This subtype was deprecated in Moose 0.84, released on June 26, 2009.
254 This will be removed entirely in Moose 2.0200.
264 =item * New release policy
266 As of the 2.0 release, Moose now has an official release and support policy,
267 documented in L<Moose::Manual::Support>. All API changes will now go through a
268 deprecation cycle of at least one year, after which the deprecated API can be
269 removed. Deprecations and removals will only happen in major releases.
271 In between major releases, we will still make minor releases to add new
272 features, fix bugs, update documentation, etc.
280 =item Configurable stacktraces
282 Classes which use the L<Moose::Error::Default> error class can now have
283 stacktraces disabled by setting the C<MOOSE_ERROR_STYLE> env var to C<croak>.
284 This is experimental, fairly incomplete, and won't work in all cases (because
285 Moose's error system in general is all of these things), but this should allow
286 for reducing at least some of the verbosity in most cases.
294 =item Native Delegations
296 In previous versions of Moose, the Native delegations were created as
297 closures. The generated code was often quite slow compared to doing the same
298 thing by hand. For example, the Array's push delegation ended up doing
301 push @{ $self->$reader() }, @_;
303 If the attribute was created without a reader, the C<$reader> sub reference
304 followed a very slow code path. Even with a reader, this is still slower than
307 Native delegations are now generated as inline code, just like other
308 accessors, so we can access the slot directly.
310 In addition, native traits now do proper constraint checking in all cases. In
311 particular, constraint checking has been improved for array and hash
312 references. Previously, only the I<contained> type (the C<Str> in
313 C<HashRef[Str]>) would be checked when a new value was added to the
314 collection. However, if there was a constraint that applied to the whole
315 value, this was never checked.
317 In addition, coercions are now called on the whole value.
319 The delegation methods now do more argument checking. All of the methods check
320 that a valid number of arguments were passed to the method. In addition, the
321 delegation methods check that the arguments are sane (array indexes, hash
322 keys, numbers, etc.) when applicable. We have tried to emulate the behavior of
323 Perl builtins as much as possible.
325 Finally, triggers are called whenever the value of the attribute is changed by
328 These changes are only likely to break code in a few cases.
330 The inlining code may or may not preserve the original reference when changes
331 are made. In some cases, methods which change the value may replace it
332 entirely. This will break tied values.
334 If you have a typed arrayref or hashref attribute where the type enforces a
335 constraint on the whole collection, this constraint will now be checked. It's
336 possible that code which previously ran without errors will now cause the
337 constraint to fail. However, presumably this is a good thing ;)
339 If you are passing invalid arguments to a delegation which were previously
340 being ignored, these calls will now fail.
342 If your code relied on the trigger only being called for a regular writer,
343 that may cause problems.
345 As always, you are encouraged to test before deploying the latest version of
348 =item Defaults is and default for String, Counter, and Bool
350 A few native traits (String, Counter, Bool) provide default values of "is" and
351 "default" when you created an attribute. Allowing them to provide these values
352 is now deprecated. Supply the value yourself when creating the attribute.
354 =item The C<meta> method
356 Moose and Class::MOP have been cleaned up internally enough to make the
357 C<meta> method that you get by default optional. C<use Moose> and
358 C<use Moose::Role> now can take an additional C<-meta_name> option, which
359 tells Moose what name to use when installing the C<meta> method. Passing
360 C<undef> to this option suppresses generation of the C<meta> method
361 entirely. This should be useful for users of modules which also use a C<meta>
362 method or function, such as L<Curses> or L<Rose::DB::Object>.
370 =item All deprecated features now warn
372 Previously, deprecation mostly consisted of simply saying "X is deprecated" in
373 the Changes file. We were not very consistent about actually warning. Now, all
374 deprecated features still present in Moose actually give a warning. The
375 warning is issued once per calling package. See L<Moose::Deprecated> for more
378 =item You cannot pass C<< coerce => 1 >> unless the attribute's type constraint has a coercion
380 Previously, this was accepted, and it sort of worked, except that if you
381 attempted to set the attribute after the object was created, you would get a
384 Now you will get a warning when you attempt to define the attribute.
386 =item C<no Moose>, C<no Moose::Role>, and C<no Moose::Exporter> no longer unimport strict and warnings
388 This change was made in 1.05, and has now been reverted. We don't know if the
389 user has explicitly loaded strict or warnings on their own, and unimporting
390 them is just broken in that case.
392 =item Reversed logic when defining which options can be changed
394 L<Moose::Meta::Attribute> now allows all options to be changed in an
395 overridden attribute. The previous behaviour required each option to be
396 whitelisted using the C<legal_options_for_inheritance> method. This method has
397 been removed, and there is a new method, C<illegal_options_for_inheritance>,
398 which can now be used to prevent certain options from being changeable.
400 In addition, we only throw an error if the illegal option is actually
401 changed. If the superclass didn't specify this option at all when defining the
402 attribute, the subclass version can still add it as an option.
404 Example of overriding this in an attribute trait:
406 package Bar::Meta::Attribute;
409 has 'my_illegal_option' => (
414 around illegal_options_for_inheritance => sub {
415 return ( shift->(@_), qw/my_illegal_option/ );
424 =item L<Moose::Object/BUILD> methods are now called when calling C<new_object>
426 Previously, C<BUILD> methods would only be called from C<Moose::Object::new>,
427 but now they are also called when constructing an object via
428 C<Moose::Meta::Class::new_object>. C<BUILD> methods are an inherent part of the
429 object construction process, and this should make C<< $meta->new_object >>
430 actually usable without forcing people to use C<< $meta->name->new >>.
432 =item C<no Moose>, C<no Moose::Role>, and C<no Moose::Exporter> now unimport strict and warnings
434 In the interest of having C<no Moose> clean up everything that C<use Moose>
435 does in the calling scope, C<no Moose> (as well as all other
436 L<Moose::Exporter>-using modules) now unimports strict and warnings.
438 =item Metaclass compatibility checking and fixing should be much more robust
440 The L<metaclass compatibility|Moose/METACLASS COMPATIBILITY AND MOOSE> checking
441 and fixing algorithms have been completely rewritten, in both Class::MOP and
442 Moose. This should resolve many confusing errors when dealing with non-Moose
443 inheritance and with custom metaclasses for things like attributes,
444 constructors, etc. For correct code, the only thing that should require a
445 change is that custom error metaclasses must now inherit from
446 L<Moose::Error::Default>.
454 =item Moose::Meta::TypeConstraint::Class is_subtype_of behavior
456 Earlier versions of L<is_subtype_of|Moose::Meta::TypeConstraint::Class/is_subtype_of>
457 would incorrectly return true when called with itself, its own TC name or
458 its class name as an argument. (i.e. $foo_tc->is_subtype_of('Foo') == 1) This
459 behavior was a caused by C<isa> being checked before the class name. The old
460 behavior can be accessed with L<is_type_of|Moose::Meta::TypeConstraint::Class/is_type_of>
468 =item Moose::Meta::Attribute::Native::Trait::Code no longer creates reader methods by default
470 Earlier versions of L<Moose::Meta::Attribute::Native::Trait::Code> created
471 read-only accessors for the attributes it's been applied to, even if you didn't
472 ask for it with C<< is => 'ro' >>. This incorrect behaviour has now been fixed.
480 =item Moose::Util add_method_modifier behavior
482 add_method_modifier (and subsequently the sugar functions Moose::before,
483 Moose::after, and Moose::around) can now accept arrayrefs, with the same
484 behavior as lists. Types other than arrayref and regexp result in an error.
488 =head1 0.93_01 and 0.94
492 =item Moose::Util::MetaRole API has changed
494 The C<apply_metaclass_roles> function is now called C<apply_metaroles>. The
495 way arguments are supplied has been changed to force you to distinguish
496 between metaroles applied to L<Moose::Meta::Class> (and helpers) versus
497 L<Moose::Meta::Role>.
499 The old API still works, but will warn in a future release, and eventually be
502 =item Moose::Meta::Role has real attributes
504 The attributes returned by L<Moose::Meta::Role> are now instances of the
505 L<Moose::Meta::Role::Attribute> class, instead of bare hash references.
507 =item "no Moose" now removes C<blessed> and C<confess>
509 Moose is now smart enough to know exactly what it exported, even when it
510 re-exports functions from other packages. When you unimport Moose, it will
511 remove these functions from your namespace unless you I<also> imported them
512 directly from their respective packages.
514 If you have a C<no Moose> in your code I<before> you call C<blessed> or
515 C<confess>, your code will break. You can either move the C<no Moose> call
516 later in your code, or explicitly import the relevant functions from the
517 packages that provide them.
519 =item L<Moose::Exporter> is smarter about unimporting re-exports
521 The change above comes from a general improvement to L<Moose::Exporter>. It
522 will now unimport any function it exports, even if that function is a
523 re-export from another package.
525 =item Attributes in roles can no longer override class attributes with "+foo"
527 Previously, this worked more or less accidentally, because role attributes
528 weren't objects. This was never documented, but a few MooseX modules took
531 =item The composition_class_roles attribute in L<Moose::Meta::Role> is now a method
533 This was done to make it possible for roles to alter the the list of
534 composition class roles by applying a method modifiers. Previously, this was
535 an attribute and MooseX modules override it. Since that no longer works, this
538 This I<should> be an attribute, so this may switch back to being an attribute
539 in the future if we can figure out how to make this work.
547 =item Calling $object->new() is no longer deprecated
549 We decided to undeprecate this. Now it just works.
551 =item Both C<get_method_map> and C<get_attribute_map> is deprecated
553 These metaclass methods were never meant to be public, and they are both now
554 deprecated. The work around if you still need the functionality they provided
555 is to iterate over the list of names manually.
557 my %fields = map { $_ => $meta->get_attribute($_) } $meta->get_attribute_list;
559 This was actually a change in L<Class::MOP>, but this version of Moose
560 requires a version of L<Class::MOP> that includes said change.
568 =item Added Native delegation for Code refs
570 See L<Moose::Meta::Attribute::Native::Trait::Code> for details.
572 =item Calling $object->new() is deprecated
574 Moose has long supported this, but it's never really been documented, and we
575 don't think this is a good practice. If you want to construct an object from
576 an existing object, you should provide some sort of alternate constructor like
577 C<< $object->clone >>.
579 Calling C<< $object->new >> now issues a warning, and will be an error in a
582 =item Moose no longer warns if you call C<make_immutable> for a class with mutable ancestors
584 While in theory this is a good thing to warn about, we found so many
585 exceptions to this that doing this properly became quite problematic.
593 =item New Native delegation methods from L<List::Util> and L<List::MoreUtils>
595 In particular, we now have C<reduce>, C<shuffle>, C<uniq>, and C<natatime>.
597 =item The Moose::Exporter with_caller feature is now deprecated
599 Use C<with_meta> instead. The C<with_caller> option will start warning in a
602 =item Moose now warns if you call C<make_immutable> for a class with mutable ancestors
604 This is dangerous because modifying a class after a subclass has been
605 immutabilized will lead to incorrect results in the subclass, due to inlining,
606 caching, etc. This occasionally happens accidentally, when a class loads one
607 of its subclasses in the middle of its class definition, so pointing out that
608 this may cause issues should be helpful. Metaclasses (classes that inherit
609 from L<Class::MOP::Object>) are currently exempt from this check, since at the
610 moment we aren't very consistent about which metaclasses we immutabilize.
612 =item C<enum> and C<duck_type> now take arrayrefs for all forms
614 Previously, calling these functions with a list would take the first element of
615 the list as the type constraint name, and use the remainder as the enum values
616 or method names. This makes the interface inconsistent with the anon-type forms
617 of these functions (which must take an arrayref), and a free-form list where
618 the first value is sometimes special is hard to validate (and harder to give
619 reasonable error messages for). These functions have been changed to take
620 arrayrefs in all their forms - so, C<< enum 'My::Type' => [qw(foo bar)] >> is
621 now the preferred way to create an enum type constraint. The old syntax still
622 works for now, but it will hopefully be deprecated and removed in a future
629 L<Moose::Meta::Attribute::Native> has been moved into the Moose core from
630 L<MooseX::AttributeHelpers>. Major changes include:
634 =item C<traits>, not C<metaclass>
636 Method providers are only available via traits.
638 =item C<handles>, not C<provides> or C<curries>
640 The C<provides> syntax was like core Moose C<< handles => HASHREF >>
641 syntax, but with the keys and values reversed. This was confusing,
642 and AttributeHelpers now uses C<< handles => HASHREF >> in a way that
643 should be intuitive to anyone already familiar with how it is used for
646 The C<curries> functionality provided by AttributeHelpers has been
647 generalized to apply to all cases of C<< handles => HASHREF >>, though
648 not every piece of functionality has been ported (currying with a
649 CODEREF is not supported).
651 =item C<empty> is now C<is_empty>, and means empty, not non-empty
653 Previously, the C<empty> method provided by Arrays and Hashes returned true if
654 the attribute was B<not> empty (no elements). Now it returns true if the
655 attribute B<is> empty. It was also renamed to C<is_empty>, to reflect this.
657 =item C<find> was renamed to C<first>, and C<first> and C<last> were removed
659 L<List::Util> refers to the functionality that we used to provide under C<find>
660 as L<first|List::Util/first>, so that will likely be more familiar (and will
661 fit in better if we decide to add more List::Util functions). C<first> and
662 C<last> were removed, since their functionality is easily duplicated with
665 =item Helpers that take a coderef of one argument now use C<$_>
667 Subroutines passed as the first argument to C<first>, C<map>, and C<grep> now
668 receive their argument in C<$_> rather than as a parameter to the subroutine.
669 Helpers that take a coderef of two or more arguments remain using the argument
670 list (there are technical limitations to using C<$a> and C<$b> like C<sort>
673 See L<Moose::Meta::Attribute::Native> for the new documentation.
677 The C<alias> and C<excludes> role parameters have been renamed to C<-alias>
678 and C<-excludes>. The old names still work, but new code should use the new
679 names, and eventually the old ones will be deprecated and removed.
683 C<< use Moose -metaclass => 'Foo' >> now does alias resolution, just like
684 C<-traits> (and the C<metaclass> and C<traits> options to C<has>).
686 Added two functions C<meta_class_alias> and C<meta_attribute_alias> to
687 L<Moose::Util>, to simplify aliasing metaclasses and metatraits. This is
688 a wrapper around the old
690 package Moose::Meta::Class::Custom::Trait::FooTrait;
691 sub register_implementation { 'My::Meta::Trait' }
697 When an attribute generates I<no> accessors, we now warn. This is to help
698 users who forget the C<is> option. If you really do not want any accessors,
699 you can use C<< is => 'bare' >>. You can maintain back compat with older
700 versions of Moose by using something like:
702 ($Moose::VERSION >= 0.84 ? is => 'bare' : ())
704 When an accessor overwrites an existing method, we now warn. To work around
705 this warning (if you really must have this behavior), you can explicitly
706 remove the method before creating it as an accessor:
710 __PACKAGE__->meta->remove_method('foo');
716 When an unknown option is passed to C<has>, we now warn. You can silence
717 the warning by fixing your code. :)
719 The C<Role> type has been deprecated. On its own, it was useless,
720 since it just checked C<< $object->can('does') >>. If you were using
721 it as a parent type, just call C<role_type('Role::Name')> to create an
722 appropriate type instead.
726 C<use Moose::Exporter;> now imports C<strict> and C<warnings> into packages
731 C<DEMOLISHALL> and C<DEMOLISH> now receive an argument indicating whether or
732 not we are in global destruction.
736 Type constraints no longer run coercions for a value that already matches the
737 constraint. This may affect some (arguably buggy) edge case coercions that
738 rely on side effects in the C<via> clause.
742 L<Moose::Exporter> now accepts the C<-metaclass> option for easily
743 overriding the metaclass (without L<metaclass>). This works for classes
748 Added a C<duck_type> sugar function to L<Moose::Util::TypeConstraints>
749 to make integration with non-Moose classes easier. It simply checks if
750 C<< $obj->can() >> a list of methods.
752 A number of methods (mostly inherited from L<Class::MOP>) have been
753 renamed with a leading underscore to indicate their internal-ness. The
754 old method names will still work for a while, but will warn that the
755 method has been renamed. In a few cases, the method will be removed
756 entirely in the future. This may affect MooseX authors who were using
761 Calling C<subtype> with a name as the only argument now throws an
762 exception. If you want an anonymous subtype do:
764 my $subtype = subtype as 'Foo';
766 This is related to the changes in version 0.71_01.
768 The C<is_needed> method in L<Moose::Meta::Method::Destructor> is now
769 only usable as a class method. Previously, it worked as a class or
770 object method, with a different internal implementation for each
773 The internals of making a class immutable changed a lot in Class::MOP
774 0.78_02, and Moose's internals have changed along with it. The
775 external C<< $metaclass->make_immutable >> method still works the same
780 A mutable class accepted C<< Foo->new(undef) >> without complaint,
781 while an immutable class would blow up with an unhelpful error. Now,
782 in both cases we throw a helpful error instead.
784 This "feature" was originally added to allow for cases such as this:
792 return My::Class->new($args);
794 But we decided this is a bad idea and a little too magical, because it
795 can easily mask real errors.
799 Calling C<type> or C<subtype> without the sugar helpers (C<as>,
800 C<where>, C<message>) is now deprecated.
802 As a side effect, this meant we ended up using Perl prototypes on
803 C<as>, and code like this will no longer work:
805 use Moose::Util::TypeConstraints;
806 use Declare::Constraints::Simple -All;
808 subtype 'ArrayOfInts'
810 => IsArrayRef(IsInt);
812 Instead it must be changed to this:
817 where => IsArrayRef(IsInt)
821 If you want to maintain backwards compat with older versions of Moose,
822 you must explicitly test Moose's C<VERSION>:
824 if ( Moose->VERSION < 0.71_01 ) {
825 subtype 'ArrayOfInts'
827 => IsArrayRef(IsInt);
833 where => IsArrayRef(IsInt)
840 We no longer pass the meta-attribute object as a final argument to
841 triggers. This actually changed for inlined code a while back, but the
842 non-inlined version and the docs were still out of date.
844 If by some chance you actually used this feature, the workaround is
845 simple. You fetch the attribute object from out of the C<$self>
846 that is passed as the first argument to trigger, like so:
852 my ( $self, $value ) = @_;
853 my $attr = $self->meta->find_attribute_by_name('foo');
861 If you created a subtype and passed a parent that Moose didn't know
862 about, it simply ignored the parent. Now it automatically creates the
863 parent as a class type. This may not be what you want, but is less
866 You could declare a name with subtype such as "Foo!Bar". Moose would
867 accept this allowed, but if you used it in a parameterized type such
868 as "ArrayRef[Foo!Bar]" it wouldn't work. We now do some vetting on
869 names created via the sugar functions, so that they can only contain
870 alphanumerics, ":", and ".".
874 Methods created via an attribute can now fulfill a C<requires>
875 declaration for a role. Honestly we don't know why Stevan didn't make
876 this work originally, he was just insane or something.
878 Stack traces from inlined code will now report the line and file as
879 being in your class, as opposed to in Moose guts.
883 When a class does not provide all of a role's required methods, the
884 error thrown now mentions all of the missing methods, as opposed to
885 just the first missing method.
887 Moose will no longer inline a constructor for your class unless it
888 inherits its constructor from Moose::Object, and will warn when it
889 doesn't inline. If you want to force inlining anyway, pass
890 C<< replace_constructor => 1 >> to C<make_immutable>.
892 If you want to get rid of the warning, pass C<< inline_constructor =>
897 Removed the (deprecated) C<make_immutable> keyword.
899 Removing an attribute from a class now also removes delegation
900 (C<handles>) methods installed for that attribute. This is correct
901 behavior, but if you were wrongly relying on it you might get bit.
905 Roles now add methods by calling C<add_method>, not
906 C<alias_method>. They make sure to always provide a method object,
907 which will be cloned internally. This means that it is now possible to
908 track the source of a method provided by a role, and even follow its
909 history through intermediate roles. This means that methods added by
910 a role now show up when looking at a class's method list/map.
912 Parameter and Union args are now sorted, this makes Int|Str the same
913 constraint as Str|Int. Also, incoming type constraint strings are
914 normalized to remove all whitespace differences. This is mostly for
915 internals and should not affect outside code.
917 L<Moose::Exporter> will no longer remove a subroutine that the
918 exporting package re-exports. Moose re-exports the Carp::confess
919 function, among others. The reasoning is that we cannot know whether
920 you have also explicitly imported those functions for your own use, so
921 we err on the safe side and always keep them.
925 C<Moose::init_meta> should now be called as a method.
927 New modules for extension writers, L<Moose::Exporter> and
928 L<Moose::Util::MetaRole>.
932 Implemented metaclass traits (and wrote a recipe for it):
934 use Moose -traits => 'Foo'
936 This should make writing small Moose extensions a little
941 Fixed C<coerce> to accept anon types just like C<subtype> can.
944 coerce $some_anon_type => from 'Str' => via { ... };
948 Added C<BUILDARGS>, a new step in C<< Moose::Object->new() >>.
952 Fixed how the C<< is => (ro|rw) >> works with custom defined
953 C<reader>, C<writer> and C<accessor> options. See the below table for
956 is => ro, writer => _foo # turns into (reader => foo, writer => _foo)
957 is => rw, writer => _foo # turns into (reader => foo, writer => _foo)
958 is => rw, accessor => _foo # turns into (accessor => _foo)
959 is => ro, accessor => _foo # error, accesor is rw
963 The C<before/around/after> method modifiers now support regexp
964 matching of method names. NOTE: this only works for classes, it is
965 currently not supported in roles, but, ... patches welcome.
967 The C<has> keyword for roles now accepts the same array ref form that
968 L<Moose>.pm does for classes.
970 A trigger on a read-only attribute is no longer an error, as it's
971 useful to trigger off of the constructor.
973 Subtypes of parameterizable types now are parameterizable types
978 Fixed issue where C<DEMOLISHALL> was eating the value in C<$@>, and so
979 not working correctly. It still kind of eats them, but so does vanilla
984 Inherited attributes may now be extended without restriction on the
985 type ('isa', 'does').
987 The entire set of Moose::Meta::TypeConstraint::* classes were
988 refactored in this release. If you were relying on their internals you
989 should test your code carefully.
993 Documenting the use of '+name' with attributes that come from recently
994 composed roles. It makes sense, people are using it, and so why not
995 just officially support it.
997 The C<< Moose::Meta::Class->create >> method now supports roles.
999 It is now possible to make anonymous enum types by passing C<enum> an
1000 array reference instead of the C<< enum $name => @values >>.
1004 Added the C<make_immutable> keyword as a shortcut to calling
1005 C<make_immutable> on the meta object. This eventually got removed!
1007 Made C<< init_arg => undef >> work in Moose. This means "do not accept
1008 a constructor parameter for this attribute".
1010 Type errors now use the provided message. Prior to this release they
1015 Moose is now a postmodern object system :)
1017 The Role system was completely refactored. It is 100% backwards
1018 compat, but the internals were totally changed. If you relied on the
1019 internals then you are advised to test carefully.
1021 Added method exclusion and aliasing for Roles in this release.
1023 Added the L<Moose::Util::TypeConstraints::OptimizedConstraints>
1026 Passing a list of values to an accessor (which is only expecting one
1027 value) used to be silently ignored, now it throws an error.
1031 Added parameterized types and did a pretty heavy refactoring of the
1032 type constraint system.
1034 Better framework extensibility and better support for "making your own
1037 =head1 0.25 or before
1039 Honestly, you shouldn't be using versions of Moose that are this old,
1040 so many bug fixes and speed improvements have been made you would be
1041 crazy to not upgrade.
1043 Also, I am tired of going through the Changelog so I am stopping here,
1044 if anyone would like to continue this please feel free.