1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
|
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 cannot 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,
);
They can also be method names as strings:
my ($set_foo);
lexical_has foo => (
reader => 'get_foo',
writer => \$set_foo,
);
This allows you to provide a partly public API for an attribute.
`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 in each pair, the first is a scalar ref or a string method
name that will be handled, and the second is a coderef or string
method name that will do the handling. (The second can be an
arrayref in the case of currying.)
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/');
Supports Sub::HandlesVia:
my $remove_task;
lexical_has tasks => (
isa => ArrayRef,
handles_via => 'Array',
handles => [
task_count => 'count',
add_task => 'push',
next_task => [ 'get', 0 ],
\$remove_task => 'unshift',
],
);
# later...
while ($self->task_count) {
my $task = $self->next_task;
my $success = $self->handle_task($task);
if ($success) {
$self->$remove_task;
}
}
`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, 2017, 2025 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.
|
