install_accessor

"package"

The package into which to install the subroutine. If this argument is omitted, it will inspect $self to determine the package. Class::Accessor::* accessor generators are typically used like this:

    __PACKAGE__
        ->mk_new
        ->mk_array_accessors(qw(foo bar));
    

Therefore "install_accessor()" can determine the right package into which to install the subroutine.

"name"

The name or names to use for the subroutine. You can either pass a single string or a reference to an array of strings. Each string is interpreted as a subroutine name inside the given package, and the code reference is installed into the appropriate typeglob.

Why would you want to install a subroutine in more than one place inside your package? For example, Class::Accessor::Complex often creates aliases so the user can choose the version of the name that reads more naturally.

An example of this usage would be:

        $self->install_accessor(
            name => [ "clear_${field}", "${field}_clear" ],
            code => sub { ... }
        );
    

"code"

This is the code reference that should be installed.

The installed subroutine is named using Sub::Name, so it shows up with a meaningful name in stack traces (instead of as "__ANON__"). However, the inside the debugger, the subroutine still shows up as "__ANON__". You might therefore want to use the following lines at the beginning of your subroutine:

        $self->install_accessor(
            name => $field,
            code => sub {
                local $DB::sub = local *__ANON__ = "${class}::${field}"
                    if defined &DB::DB && !$Devel::DProf::VERSION;
                ...
        );

Now the subroutine will be named both in a stack trace and inside the debugger.

document_accessor

Takes as arguments a named hash. The following keys are recognized:

"package"

Like the "package" argument of "install_accessor()".

"name"

The name of the accessor being documented. This can be a string or a reference to an array of strings, if the same documentation applies to more than one method. This can occur, for example, when there are aliases for a method such as "clear_foo()" and "foo_clear()".

"purpose"

A string describing the generated method.

"examples"

An array reference containing one or more examples of using the method. These will also be used in the generated documentation.

You can pass additional arbitrary key/value pairs; they will be stored as well. It depends on your documentation tool which keys are useful. For example, Class::Accessor::Complex generates and Pod::Weaver::Section::CollectWithAutoDoc supports a "belongs_to" key that shows which generated helper method belongs to which main accessor.