NAME MooseX::Deprecated - mark attributes and methods as deprecated SYNOPSIS package Goose { use Moose; has feathers => (is => 'ro'); sub honk { say "Honk!" } with "MooseX::Deprecated" => { attributes => [ "feathers" ], methods => [ "honk" ], }; } DESCRIPTION MooseX::Deprecated is a parameterizable role that makes it easy to deprecate particular attributes and methods in a class. In the SYNOPSIS above, `before` method modifiers will be installed on the `feathers` accessor and the `honk` method, issuing a deprecation warning. Additionally, an `after` modifier will be installed on the class' `BUILD` method which will issue deprecation warnings for any deprecated attributes passed to the constructor. The warning text will be something along the lines of: "%s is a deprecated %s" Warnings are issued in the "deprecated" warnings category, so can be disabled using: no warnings qw( deprecated ); Warnings can be upgraded to fatal errors with: use warnings FATAL => qw( deprecated ); When consuming the role you *must* pass either a list of attributes, or a list of methods, or both, as parameters to the role. If you forget to do so, you'll get an error message like: "%s with no list of attributes or methods". CAVEATS To deprecate an attribute, the attribute must actually exist at the time you consume this role. In particular, this will not work: package Goose { use Moose; with "MooseX::Deprecated" => { attributes => [ "feathers" ], }; has feathers => (is => 'ro'); } Because the "feathers" attribute isn't defined until *after* the role is consumed. Attempting the above will die with a nasty error message: "Attribute %s does not exist in %s so cannot be deprecated". If a deprecated attribute handles any methods via delegation, then calling these methods will result in not one, but two warnings. One warning for calling the delegated method; the other warning for calling the accessor (reader) to obtain the object to delegate to. This could theoretically be changed, but I'm comfortable with the existing situation. In mutable classes, warnings issued from the constructor will appear to come from Moose's innards, and not from the constructor's real call site. This means that disabling them or fatalizing them with `no warnings` or `use warnings FATAL` will not work. You should always make classes immutable anyway. Warnings issued by the accessor (reader) during method delegation will similarly not be issued from the correct call site, affecting your ability to disable or fatalize them. Making the class immutable cannot fix this one I'm afraid. BUGS Please report any bugs to . SEE ALSO Package::DeprecationManager provides a more powerful and complicated set of features. I'm a simple kind of guy, and don't see the need to allow my caller to pick and choose which deprecations they'd like to ignore based on some API version. Attribute::Deprecated is cute, but only deals with methods, and ironically not (what Moose calls) attributes. Devel::Deprecation has some pretty nice features, but is more manual than I'd like, and again only deals with methods. . AUTHOR Toby Inkster . COPYRIGHT AND LICENCE This software is copyright (c) 2013 by Toby Inkster. This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself. DISCLAIMER OF WARRANTIES THIS PACKAGE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.