NAME

    MooseX::AttributeShortcuts - Shorthand for common attribute options

VERSION

    This document describes version 0.037 of MooseX::AttributeShortcuts -
    released November 20, 2017 as part of MooseX-AttributeShortcuts.

SYNOPSIS

        package Some::Class;
    
        use Moose;
        use MooseX::AttributeShortcuts;
    
        # same as:
        #   is => 'ro', lazy => 1, builder => '_build_foo'
        has foo => (is => 'lazy');
    
        # same as: is => 'ro', writer => '_set_foo'
        has foo => (is => 'rwp');
    
        # same as: is => 'ro', builder => '_build_bar'
        has bar => (is => 'ro', builder => 1);
    
        # same as: is => 'ro', clearer => 'clear_bar'
        has bar => (is => 'ro', clearer => 1);
    
        # same as: is => 'ro', predicate => 'has_bar'
        has bar => (is => 'ro', predicate => 1);
    
        # works as you'd expect for "private": predicate => '_has_bar'
        has _bar => (is => 'ro', predicate => 1);
    
        # extending? Use the "Shortcuts" trait alias
        extends 'Some::OtherClass';
        has '+bar' => (traits => [Shortcuts], builder => 1, ...);

DESCRIPTION

    Ever find yourself repeatedly specifying writers and builders, because
    there's no good shortcut to specifying them? Sometimes you want an
    attribute to have a read-only public interface, but a private writer.
    And wouldn't it be easier to just say builder => 1 and have the
    attribute construct the canonical _build_$name builder name for you?

    This package causes an attribute trait to be applied to all attributes
    defined to the using class. This trait extends the attribute option
    processing to handle the above variations. All attribute options as
    described in Moose or Class::MOP::Attribute remain usable, just as when
    this trait is not applied.

 Some Notes On History

    Moose has long had a lazy_build attribute option. It was once
    considered a best practice, but that has, ah, changed. This trait began
    as a desire to still leverage bits of lazy_build (and a tacit
    acknowledgment that fat-finger bugs rank among the most embarrassing,
    right up there with "the TV was unplugged the entire time").

    This author does not recommend you use lazy_build, unless you know
    exactly what you're doing (probably) and that it's a good idea
    (probably not).

    Nonetheless, this lazy_build option is why we set certain options the
    way we do below; while lazy_build in its entirety is not optimal, it
    had the right idea: regular, predictable accessor names for regular,
    predictable attribute options.

    As an example, just looking at the below it doesn't seem logical that:

        has _foo => (is => 'ro', clearer => 1);

    ...becomes:

        has _foo => (is => 'ro', clearer => '_clear_foo');

    After reading the lazy_build attribute option, however, we see that the
    choice had already been made for us.

USAGE

    This package automatically applies an attribute metaclass trait. Simply
    using this package causes the trait to be applied by default to your
    attribute's metaclasses.

EXTENDING A CLASS

    If you're extending a class and trying to extend its attributes as
    well, you'll find out that the trait is only applied to attributes
    defined locally in the class. This package exports a trait shortcut
    function Shortcuts that will help you apply this to the extended
    attribute:

        has '+something' => (traits => [Shortcuts], ...);

NEW ATTRIBUTE OPTIONS

    Unless specified here, all options defined by Moose::Meta::Attribute
    and Class::MOP::Attribute remain unchanged.

    Want to see additional options? Ask, or better yet, fork on GitHub and
    send a pull request. If the shortcuts you're asking for already exist
    in Moo or Mouse or elsewhere, please note that as it will carry
    significant weight.

    For the following, $name should be read as the attribute name; and the
    various prefixes should be read using the defaults.

 is => 'rwp'

    Specifying is => 'rwp' will cause the following options to be set:

        is     => 'ro'
        writer => "_set_$name"

    rwp can be read as "read + write private".

 is => 'lazy'

    Specifying is => 'lazy' will cause the following options to be set:

        is       => 'ro'
        builder  => "_build_$name"
        lazy     => 1

    NOTE: Since 0.009 we no longer set init_arg => undef if no init_arg is
    explicitly provided. This is a change made in parallel with Moo, based
    on a large number of people surprised that lazy also made one's
    init_def undefined.

 is => 'lazy', default => ...

    Specifying is => 'lazy' and a default will cause the following options
    to be set:

        is       => 'ro'
        lazy     => 1
        default  => ... # as provided

    That is, if you specify is => 'lazy' and also provide a default, then
    we won't try to set a builder, as well.

 builder => 1

    Specifying builder => 1 will cause the following options to be set:

        builder => "_build_$name"

 builder => sub { ... }

    Passing a coderef to builder will cause that coderef to be installed in
    the class this attribute is associated with the name you'd expect, and
    builder => 1 to be set.

    e.g., in your class (or role),

        has foo => (is => 'ro', builder => sub { 'bar!' });

    ...is effectively the same as...

        has foo => (is => 'ro', builder => '_build_foo');
        sub _build_foo { 'bar!' }

    The behaviour of this option in roles changed in 0.030, and the builder
    methods will be installed in the role itself. This means you can
    alias/exclude/etc builder methods in roles, just as you can with any
    other method.

 clearer => 1

    Specifying clearer => 1 will cause the following options to be set:

        clearer => "clear_$name"

    or, if your attribute name begins with an underscore:

        clearer => "_clear$name"

    (that is, an attribute named _foo would get _clear_foo)

 predicate => 1

    Specifying predicate => 1 will cause the following options to be set:

        predicate => "has_$name"

    or, if your attribute name begins with an underscore:

        predicate => "_has$name"

    (that is, an attribute named _foo would get _has_foo)

 init_arg => 1 / -1

    This is a somewhat esoteric shortcut; you probably don't want to use
    this (or even read this section).

    Specifying init_arg => 1 will cause the following options to be set:

        # attribute: "name"
        init_arg => 'name'
    
        # or, attribute: "_name"
        init_arg => '_name'

    ...while init_arg => -1 will cause the following options to be set:

        # attribute: "name"
        init_arg => '_name'
    
        # or, attribute: "_name"
        init_arg => 'name'

 trigger => 1

    Specifying trigger => 1 will cause the attribute to be created with a
    trigger that calls a named method in the class with the options passed
    to the trigger. By default, the method name the trigger calls is the
    name of the attribute prefixed with _trigger_.

    e.g., for an attribute named foo this would be equivalent to:

        trigger => sub { shift->_trigger_foo(@_) }

    For an attribute named _foo:

        trigger => sub { shift->_trigger__foo(@_) }

    This naming scheme, in which the trigger is always private, is the same
    as the builder naming scheme (just with a different prefix).

 handles => { foo => sub { ... }, ... }

    Creating a delegation with a coderef will now create a new, "custom
    accessor" for the attribute. These coderefs will be installed and
    called as methods on the associated class (just as readers, writers,
    and other accessors are), and will have the attribute metaclass
    available in $_. Anything the accessor is called with it will have
    access to in @_, just as you'd expect of a method.

    e.g., the following example creates an attribute named bar with a
    standard reader accessor named bar and two custom accessors named foo
    and foo_too.

        has bar => (
    
            is      => 'ro',
            isa     => 'Int',
            handles => {
    
                foo => sub {
                    my $self = shift @_;
    
                    return $_->get_value($self) + 1;
                },
    
                foo_too => sub {
                    my $self = shift @_;
    
                    return $self->bar + 1;
                },
    
                # ...as you'd expect.
                bar => 'bar',
            },
        );

    ...and later,

    Note that in this example both foo() and foo_too() do effectively the
    same thing: return the attribute's current value plus 1. However, foo()
    accesses the attribute value directly through the metaclass, the pros
    and cons of which this author leaves as an exercise for the reader to
    determine.

    You may choose to use the installed accessors to get at the attribute's
    value, or use the direct metaclass access, your choice.

ANONYMOUS SUBTYPING AND COERCION

        "Abusus non tollit usum."

    Note that we create new, anonymous subtypes whenever the constraint or
    coercion options are specified in such a way that the Shortcuts trait
    (this one) is invoked. It's fully supported to use both constraint and
    coerce options at the same time.

    This facility is intended to assist with the creation of one-off type
    constraints and coercions. It is not possible to deliberately reuse the
    subtypes we create, and if you find yourself using a particular isa /
    constraint / coerce option triplet in more than one place you should
    really think about creating a type that you can reuse. MooseX::Types
    provides the facilities to easily do this, or even a simple constant
    definition at the package level with an anonymous type stashed away for
    local use.

 isa => sub { ... }

        has foo => (
            is  => 'rw',
            # $_ == $_[0] == the value to be validated
            isa => sub { die unless $_[0] == 1 },
        );
    
        # passes constraint
        $thing->foo(1);
    
        # fails constraint
        $thing->foo(5);

    Given a coderef, create a type constraint for the attribute. This
    constraint will fail if the coderef dies, and pass otherwise.

    Astute users will note that this is the same way Moo constraints work;
    we use MooseX::Meta::TypeConstraint::Mooish to implement the
    constraint.

 isa_instance_of => ...

    Given a package name, this option will create an isa type constraint
    that requires the value of the attribute be an instance of the class
    (or a descendant class) given. That is,

        has foo => (is => 'ro', isa_instance_of => 'SomeThing');

    ...is effectively the same as:

        use Moose::TypeConstraints 'class_type';
        has foo => (
            is  => 'ro',
            isa => class_type('SomeThing'),
        );

    ...but a touch less awkward.

 isa => ..., constraint => sub { ... }

    Specifying the constraint option with a coderef will cause a new
    subtype constraint to be created, with the parent type being the type
    specified in the isa option and the constraint being the coderef
    supplied here.

    For example, only integers greater than 10 will pass this attribute's
    type constraint:

        # value must be an integer greater than 10 to pass the constraint
        has thinger => (
            isa        => 'Int',
            constraint => sub { $_ > 10 },
            # ...
        );

    Note that if you supply a constraint, you must also provide an isa.

 isa => ..., constraint => sub { ... }, coerce => 1

    Supplying a constraint and asking for coercion will "Just Work", that
    is, any coercions that the isa type has will still work.

    For example, let's say that you're using the File type constraint from
    MooseX::Types::Path::Class, and you want an additional constraint that
    the file must exist:

        has thinger => (
            is         => 'ro',
            isa        => File,
            constraint => sub { !! $_->stat },
            coerce     => 1,
        );

    thinger will correctly coerce the string "/etc/passwd" to a
    Path::Class:File, and will only accept the coerced result as a value if
    the file exists.

 coerce => [ Type => sub { ...coerce... }, ... ]

    Specifying the coerce option with a hashref will cause a new subtype to
    be created and used (just as with the constraint option, above), with
    the specified coercions added to the list. In the passed hashref, the
    keys are Moose types (well, strings resolvable to Moose types), and the
    values are coderefs that will coerce a given type to our type.

        has bar => (
            is     => 'ro',
            isa    => 'Str',
            coerce => [
                Int    => sub { "$_"                       },
                Object => sub { 'An instance of ' . ref $_ },
            ],
        );

INTERACTIONS WITH OTHER ATTRIBUTE TRAITS

    Sometimes attribute traits interact in surprising ways. This trait is
    well behaved; if you have discovered any interactions with other traits
    (good, bad, indifferent, etc), please report this
    <https://github.com/RsrchBoy/moosex-attributeshortcuts/issues/new> so
    that it can be worked around, fixed, or documented, as appropriate.

 MooseX::SemiAffordanceAccessor

    MooseX::SemiAffordanceAccessor changes how the is => 'rw' and accessor
    => ... attribute options work. If our trait detects that an attribute
    has had the MooseX::SemiAffordanceAccessor attribute trait applied,
    then we change our behaviour to conform to its expectations:

      * is => 'rwp'

      This:

          has  foo => (is => 'rwp');
          has _bar => (is => 'rwp');

      ...is now effectively equivalent to:

          has foo  => (is => 'ro', writer => '_set_foo');
          has _bar => (is => 'ro', writer => '_set_bar')

      * -writer_prefix is ignored

      ...as MooseX::SemiAffordanceAccessor has its own specific ideas as to
      how writers should look.

SEE ALSO

    Please see those modules/websites for more information related to this
    module.

      * Moo

      * MooseX::Types

      * MooseX::SemiAffordanceAccessor

BUGS

    Please report any bugs or feature requests on the bugtracker website
    https://github.com/RsrchBoy/moosex-attributeshortcuts/issues

    When submitting a bug or request, please include a test-file or a patch
    to an existing test-file that illustrates the bug or desired feature.

AUTHOR

    Chris Weyl <cweyl@alumni.drew.edu>

CONTRIBUTORS

      * David Steinbrunner <dsteinbrunner@pobox.com>

      * Graham Knop <haarg@haarg.org>

      * Karen Etheridge <ether@cpan.org>

      * Olaf Alders <olaf@wundersolutions.com>

COPYRIGHT AND LICENSE

    This software is Copyright (c) 2017, 2015, 2014, 2013, 2012, 2011 by
    Chris Weyl.

    This is free software, licensed under:

      The GNU Lesser General Public License, Version 2.1, February 1999