=head3 Persistent variables via state()
-Beginning with perl 5.9.4, you can declare variables with the C<state>
-keyword in place of C<my>. For that to work, though, you must have
+Beginning with Perl 5.9.4, you can declare variables with the C<state>
+keyword in place of C<my>. For that to work, though, you must have
enabled that feature beforehand, either by using the C<feature> pragma, or
-by using C<-E> on one-liners. (see L<feature>)
+by using C<-E> on one-liners (see L<feature>). Beginning with Perl 5.16,
+you can also write it as C<CORE::state>, which does not require the
+C<feature> pragma.
For example, the following code maintains a private counter, incremented
each time the gimme_another() function is called:
=head2 Lvalue subroutines
X<lvalue> X<subroutine, lvalue>
+B<WARNING>: Lvalue subroutines are still experimental and the
+implementation may change in future versions of Perl.
+
It is possible to return a modifiable value from a subroutine.
To do this, you have to declare the subroutine to return an lvalue.
my $val;
sub canmod : lvalue {
- $val; # or "return $val;"
+ $val; # or: return $val;
}
sub nomod {
$val;
all the subroutines are called in a list context.
-Lvalue subroutines are convenient, but there are some things to keep
-in mind.
+=over 4
+
+=item Lvalue subroutines are EXPERIMENTAL
+
+They appear to be convenient, but there is at least one reason to be
+circumspect.
+
+They violate encapsulation. A normal mutator can check the supplied
+argument before setting the attribute it is protecting, an lvalue
+subroutine never gets that chance. Consider;
-You can only return scalar lvalues.
+ my $some_array_ref = []; # protected by mutators ??
-When used with objects, they violate encapsulation. A normal mutator
-can check the supplied argument before setting the attribute it is
-protecting, an lvalue subroutine cannot.
+ sub set_arr { # normal mutator
+ my $val = shift;
+ die("expected array, you supplied ", ref $val)
+ unless ref $val eq 'ARRAY';
+ $some_array_ref = $val;
+ }
+ sub set_arr_lv : lvalue { # lvalue mutator
+ $some_array_ref;
+ }
-Lvalue subroutines are most valuable to contruct simple data
-structures that do not require any special processing when storing and
-retrieving the values.
+ # set_arr_lv cannot stop this !
+ set_arr_lv() = { a => 1 };
+
+=back
=head2 Passing Symbol Table Entries (typeglobs)
X<typeglob> X<*>
a local alias.
{
- local *grow = \&shrink; # only until this block exists
+ local *grow = \&shrink; # only until this block exits
grow(); # really calls shrink()
move(); # if move() grow()s, it shrink()s too
}
Any backslashed prototype character represents an actual argument
that must start with that character (optionally preceded by C<my>,
-C<our> or C<local>), with the exception of C<$>, which will accept a
-hash or array element even without a dollar sign, such as
+C<our> or C<local>), with the exception of C<$>, which will
+accept any scalar lvalue expression, such as C<$foo = 7> or
C<< my_function()->[0] >>. The value passed as part of C<@_> will be a
reference to the actual argument given in the subroutine call,
obtained by applying C<\> to that argument.
mytime +2;
you'll get C<mytime() + 2>, not C<mytime(2)>, which is how it would be parsed
-without a prototype.
+without a prototype. If you want to force a unary function to have the
+same precedence as a list operator, add C<;> to the end of the prototype:
+
+ sub mygetprotobynumber($;);
+ mygetprotobynumber $a > $b; # parsed as mygetprotobynumber($a > $b)
The interesting thing about C<&> is that you can generate new syntax with it,
provided it's in the initial position:
saying C<CORE::open()> always refers to the built-in C<open()>, even
if the current package has imported some other subroutine called
C<&open()> from elsewhere. Even though it looks like a regular
-function call, it isn't: you can't take a reference to it, such as
-the incorrect C<\&CORE::open> might appear to produce.
+function call, it isn't: the CORE:: prefix in that case is part of Perl's
+syntax, and works for any keyword, regardless of what is in the CORE
+package. Taking a reference to it, that is, C<\&CORE::open>, only works
+for some keywords. See L<CORE>.
Library modules should not in general export built-in names like C<open>
or C<chdir> as part of their default C<@EXPORT> list, because these may
See L<perlembed> if you'd like to learn about calling Perl subroutines from C.
See L<perlmod> to learn about bundling up your functions in separate files.
See L<perlmodlib> to learn what library modules come standard on your system.
-See L<perltoot> to learn how to make object method calls.
+See L<perlootut> to learn how to make object method calls.
https://perl5.git.perl.org / perl5.git / blobdiff