NAME

       Lexical::Accessor - true private attributes for Moose/Moo/Mouse

SYNOPSIS

          my $accessor = lexical_has identifier => (
             is       => 'rw',
             isa      => Int,
             default  => sub { 0 },
          );

          # or...
          lexical_has identifier => (
             is       => 'rw',
             isa      => Int,
             default  => sub { 0 },
             accessor => \$accessor,
          );

          # later...
          say $self->$accessor;     # says 0
          $self->$accessor( 1 );    # setter
          say $self->$accessor;     # says 1

DESCRIPTION

       Lexical::Accessor generates coderefs which can be used as methods to access private
       attributes for objects.

       The private attributes are stored inside-out, and do not add any accessors to the class'
       namespace, so are completely invisible to any outside code, including any subclasses. This
       gives your attribute complete privacy: subclasses can define a private (or even public)
       attribute with the same name as your private one and they will not interfere with each
       other.

       Private attributes can not be initialized by Moose/Moo/Mouse constructors, but you can
       safely initialize them inside a "BUILD" sub.

   Functions
       "lexical_has $name?, %options"
           This module exports a function lexical_has which acts much like Moose's "has"
           function, but sets up a private (lexical) attribute instead of a public one.

           Because lexical attributes are stored inside-out, the $name is completely optional;
           however a name is recommended because it allows better error messages to be generated.

           The lexical_has function supports the following options:

           "is"
               Moose/Mouse/Moo-style "ro", "rw", "rwp" and "lazy" values are supported. These
               control what sort of coderef is returned by the "lexical_has" function itself.

                  my $reader            = lexical_has "foo" => (is => "ro");
                  my $accessor          = lexical_has "foo" => (is => "rw");
                  my ($reader, $writer) = lexical_has "foo" => (is => "rwp");

               If generating more than one method it is probably clearer to pass in scalar
               references to the "reader", "writer", etc methods, rather than relying on the
               return value of the "lexical_has" function.

           "reader", "writer", "accessor", "predicate", "clearer"
               These accept scalar references. The relevant coderefs will be plonked into them:

                  my ($get_foo, $set_foo);

                  lexical_has foo => (
                     reader      => \$get_foo,
                     writer      => \$set_foo,
                  );

           "default", "builder", "lazy"
               Lazy defaults and builders are allowed. Eager (non-lazy) defaults and builders are
               currently disallowed. (Use a "BUILD" sub to set private attribute values at object
               construction time.)

               The default may be either a non-reference value, or a coderef which will be called
               as a method to return the value.

               Builders probably make less sense than defaults because they require a method in
               the class' namespace. The builder may be a method name, or the special value '1'
               which will be interpreted as meaning the attribute name prefixed by "_build_". If
               a coderef is provided, this is automatically installed into the class' namespace
               with the "_build_" prefix. (This last feature requires Sub::Name.)

           "isa"
               A type constraint for the attribute. Moo-style coderefs are accepted (including
               those generated by MooX::Types::MooseLike), as are
               Moose::Meta::TypeConstraint/MooseX::Types objects, and
               Mouse::Meta::TypeConstraint/MouseX::Types objects, and of course Type::Tiny type
               constraints.

               String type constraints may also be accepted, but only if Type::Utils is
               installed. (String type constraints are reified using "dwim_type".)

           "does"
               As an alternative to "isa", you can provide a role name in the "does" option.

           "coerce"
               A coderef or Type::Coercion object is accepted.

               If the special value '1' is provided, the type constraint object is consulted to
               find the coercion. (This doesn't work for coderef type constraints.)

           "trigger"
               A method name or coderef to trigger when a new value is set.

           "auto_deref"
               Boolean indicating whether to automatically dereference array and hash values if
               called in list context.

           "init_arg"
               Must be "undef" if provided at all.

           "required"
               Must be false if provided at all.

           "weak_ref"
               Boolean. Makes the setter weaken any references it is called with.

           "handles"
               Delegates methods. Has slightly different syntax to Moose's option of the same
               name - is required to be an arrayref of pairs such that each pair is a scalar ref
               followed by a method name, a coderef, or an arrayref (where the first element is a
               method name or coderef and subsequent elements are curried arguments).

                  my ($get, $post);

                  lexical_has ua => (
                     isa      => 'HTTP::Tiny',
                     default  => sub { 'HTTP::Tiny'->new },
                     handles  => [
                        \$get   => 'get',
                        \$post  => 'post',
                     ],
                  );

                  # later...
                  my $response = $self->$get('http://example.net/');

           "initializer", "traits", "lazy_build"
               Not currently implemented. Providing any of these options throws an error.

           "documentation", "definition_context"
               Don't do anything, but are allowed; effectively inline comments.

   Class Methods
       "lexical_has"
           This function may also be called as a class method.

   Comparison (benchmarking, etc)
       Lexical::Accessor is almost three times faster than MooX::PrivateAttributes, and almost
       twenty time faster than MooseX::Privacy. I'd also argue that it's a more "correct"
       implementation of private accessors as (short of performing impressive PadWalker
       manipulations), the accessors generated by this module are completely invisible to
       subclasses, method dispatch, etc.

       Compared to the usual Moose convention of using a leading underscore to indicate a private
       method (which is a very loose convention; it is quite common for subclasses to override
       such methods!), Lexical::Accessor clearly offers much better method privacy. There should
       be little performance hit from using lexical accessors compared to normal Moose accessors.
       (However they are nowhere near the speed of the XS-powered accessors that Moo sometimes
       uses and Mouse usually uses.)

       See also: "examples/benchmark.pl" bundled with this release.

BUGS

       Please report any bugs to <http://rt.cpan.org/Dist/Display.html?Queue=Lexical-Accessor>.

SUPPORT

       IRC: support is available through in the #moops channel on irc.perl.org
       <http://www.irc.perl.org/channels.html>.

SEE ALSO

       MooX::PrivateAttributes, MooX::ProtectedAttributes, MooseX::Privacy, Sub::Private,
       Method::Lexical, etc...

AUTHOR

       Toby Inkster <tobyink@cpan.org>.

COPYRIGHT AND LICENCE

       This software is copyright (c) 2013-2014 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.