• the two built-in subroutine attributes: method and lvalue.
• custom subroutine attributes defined using the per-package function MODIFY_CODE_ATTRIBUTES and FETCH_CODE_ATTRIBUTES.
• custom subroutine attributes defined using Attribute::Handlers

The built-in attributes are integrated into the compilation process and can affect what counts as legal syntax (e.g. lvalue). In addition to the two built-in attributes listed above, there are two version specific subroutine attributes that you might see in older code:

• locked which was used in the threaded version of Perl 5.005 and deprecated thereafter.
• assertion which was added in 5.9.0 and removed in 5.10.0 because it made code disappear when maybe it shouldn't - see the assertion pragma for a discussion and further links.

As there are very few built-in attributes, Perl and its extensions provide two mechanisms for custom attribute definitions. Common reasons to use custom attributes are

1. generation of a wrapper function that inserts code before and after the subroutine call. The code assigned to the subroutine name is replaced by the code making before+call+after code. For example, you might want to log the input parameters and return values of a call.
2. generation supplemental functions and data based on the actual attributes.
3. compilation messages and metadata statistics for use by frameworks (e.g. Catalyst and MooseClass::Std).

Custom attributes defined using FETCH_CODE_ATTRIBUTES and MODIFY_CODE_ATTRIBUTES can be used safely under mod_perl but only handle use cases 2 and 3 above. They can't be used to generate wrappers that replace subroutine definitions (use case 1) because MODIFY_CODE_ATTRIBUTES is called before the function body has been defined and inserted into the symbol table.

Attribute::Handlers can be used for all three purposes, but it relies on the CHECK and INIT phases for loading up a module and these don't get triggered under mod_perl or in other environments that rely on eval to load code. The issues related to the two different methods for defining custom attributes has been discussed at length in the following threads:

• Support for attributes:get in Attribute::Handlers?
• Is there a way to access the name under which a subroutine was first defined?
• Attribute Handlers don't run when called at run time.

For examples using customized attributes, see the following links:

• Attributes with new to manage parameters - a nice example of MODIFY_CODE_ATTRIBUTES and FETCH_CODE_ATTRIBUTES used within a single module.
• subroutine attributes and ISA - discusses how to get custom attribute definitions to be inherited by subclasses - with sample code.
• Re: Support for attributes:get in Attribute::Handlers? - an example of a module whose import routine automatically defines the MODIFY_CODE_ATTRIBUTES and FETCH_CODE_ATTRIBUTES routines for each module where it is included via use
• Hidden Treasures of the Perl Core, Part II - has an example using Attribute::Handlers to redefine a function.

Best, beth

... compilation messages and metadata statistics for use by frameworks (e.g. Catalyst and Moose).

Actually, Moose does not and never will use attributes. As perrin says below, they are best avoided at all costs. The API to use them is horrid and the limitations of that API are (IMO at least) totally unacceptable. Even Catalyst will eventually do away with attributes in favor of using something similar to how Moose works or something more radical like Devel::Declare.

-stvn

My advice is to avoid them in almost all circumstances.

I was reading Ovid's article on Test::Class just now, and noticed that Test::Class does use subroutine attributes rather extensively.

I'd appreciate if you could comment on that. Is Test::Class the exception in "almost"? Or do you and the author of Test::Class simply disagree on the usefulness of attributes?


All dogma is stupid.

I use Test::Class. The sub attributes it uses are relatively simple (nothing too perl), which is good because it makes them harder to screw up. However, I don't find them an improvement over a simple config data structure.

Catalyst uses them in Controllers to tell the dispatcher where to send requests

(Response withdrawn.)