Commit | Line | Data |
a0d0e21e |
1 | =head1 NAME |
d74e8afc |
2 | X<subroutine> X<function> |
a0d0e21e |
3 | |
4 | perlsub - Perl subroutines |
5 | |
6 | =head1 SYNOPSIS |
7 | |
8 | To declare subroutines: |
d74e8afc |
9 | X<subroutine, declaration> X<sub> |
a0d0e21e |
10 | |
09bef843 |
11 | sub NAME; # A "forward" declaration. |
12 | sub NAME(PROTO); # ditto, but with prototypes |
13 | sub NAME : ATTRS; # with attributes |
14 | sub NAME(PROTO) : ATTRS; # with attributes and prototypes |
cb1a09d0 |
15 | |
09bef843 |
16 | sub NAME BLOCK # A declaration and a definition. |
17 | sub NAME(PROTO) BLOCK # ditto, but with prototypes |
18 | sub NAME : ATTRS BLOCK # with attributes |
19 | sub NAME(PROTO) : ATTRS BLOCK # with prototypes and attributes |
a0d0e21e |
20 | |
748a9306 |
21 | To define an anonymous subroutine at runtime: |
d74e8afc |
22 | X<subroutine, anonymous> |
748a9306 |
23 | |
09bef843 |
24 | $subref = sub BLOCK; # no proto |
25 | $subref = sub (PROTO) BLOCK; # with proto |
26 | $subref = sub : ATTRS BLOCK; # with attributes |
27 | $subref = sub (PROTO) : ATTRS BLOCK; # with proto and attributes |
748a9306 |
28 | |
a0d0e21e |
29 | To import subroutines: |
d74e8afc |
30 | X<import> |
a0d0e21e |
31 | |
19799a22 |
32 | use MODULE qw(NAME1 NAME2 NAME3); |
a0d0e21e |
33 | |
34 | To call subroutines: |
d74e8afc |
35 | X<subroutine, call> X<call> |
a0d0e21e |
36 | |
5f05dabc |
37 | NAME(LIST); # & is optional with parentheses. |
54310121 |
38 | NAME LIST; # Parentheses optional if predeclared/imported. |
19799a22 |
39 | &NAME(LIST); # Circumvent prototypes. |
5a964f20 |
40 | &NAME; # Makes current @_ visible to called subroutine. |
a0d0e21e |
41 | |
42 | =head1 DESCRIPTION |
43 | |
19799a22 |
44 | Like many languages, Perl provides for user-defined subroutines. |
45 | These may be located anywhere in the main program, loaded in from |
46 | other files via the C<do>, C<require>, or C<use> keywords, or |
be3174d2 |
47 | generated on the fly using C<eval> or anonymous subroutines. |
19799a22 |
48 | You can even call a function indirectly using a variable containing |
49 | its name or a CODE reference. |
cb1a09d0 |
50 | |
51 | The Perl model for function call and return values is simple: all |
52 | functions are passed as parameters one single flat list of scalars, and |
53 | all functions likewise return to their caller one single flat list of |
54 | scalars. Any arrays or hashes in these call and return lists will |
55 | collapse, losing their identities--but you may always use |
56 | pass-by-reference instead to avoid this. Both call and return lists may |
57 | contain as many or as few scalar elements as you'd like. (Often a |
58 | function without an explicit return statement is called a subroutine, but |
19799a22 |
59 | there's really no difference from Perl's perspective.) |
d74e8afc |
60 | X<subroutine, parameter> X<parameter> |
19799a22 |
61 | |
62 | Any arguments passed in show up in the array C<@_>. Therefore, if |
63 | you called a function with two arguments, those would be stored in |
64 | C<$_[0]> and C<$_[1]>. The array C<@_> is a local array, but its |
65 | elements are aliases for the actual scalar parameters. In particular, |
66 | if an element C<$_[0]> is updated, the corresponding argument is |
67 | updated (or an error occurs if it is not updatable). If an argument |
68 | is an array or hash element which did not exist when the function |
69 | was called, that element is created only when (and if) it is modified |
70 | or a reference to it is taken. (Some earlier versions of Perl |
71 | created the element whether or not the element was assigned to.) |
72 | Assigning to the whole array C<@_> removes that aliasing, and does |
73 | not update any arguments. |
d74e8afc |
74 | X<subroutine, argument> X<argument> X<@_> |
19799a22 |
75 | |
dbb128be |
76 | A C<return> statement may be used to exit a subroutine, optionally |
77 | specifying the returned value, which will be evaluated in the |
78 | appropriate context (list, scalar, or void) depending on the context of |
79 | the subroutine call. If you specify no return value, the subroutine |
80 | returns an empty list in list context, the undefined value in scalar |
81 | context, or nothing in void context. If you return one or more |
82 | aggregates (arrays and hashes), these will be flattened together into |
83 | one large indistinguishable list. |
84 | |
85 | If no C<return> is found and if the last statement is an expression, its |
9a989771 |
86 | value is returned. If the last statement is a loop control structure |
87 | like a C<foreach> or a C<while>, the returned value is unspecified. The |
88 | empty sub returns the empty list. |
d74e8afc |
89 | X<subroutine, return value> X<return value> X<return> |
19799a22 |
90 | |
91 | Perl does not have named formal parameters. In practice all you |
92 | do is assign to a C<my()> list of these. Variables that aren't |
93 | declared to be private are global variables. For gory details |
94 | on creating private variables, see L<"Private Variables via my()"> |
95 | and L<"Temporary Values via local()">. To create protected |
96 | environments for a set of functions in a separate package (and |
97 | probably a separate file), see L<perlmod/"Packages">. |
d74e8afc |
98 | X<formal parameter> X<parameter, formal> |
a0d0e21e |
99 | |
100 | Example: |
101 | |
cb1a09d0 |
102 | sub max { |
103 | my $max = shift(@_); |
a0d0e21e |
104 | foreach $foo (@_) { |
105 | $max = $foo if $max < $foo; |
106 | } |
cb1a09d0 |
107 | return $max; |
a0d0e21e |
108 | } |
cb1a09d0 |
109 | $bestday = max($mon,$tue,$wed,$thu,$fri); |
a0d0e21e |
110 | |
111 | Example: |
112 | |
113 | # get a line, combining continuation lines |
114 | # that start with whitespace |
115 | |
116 | sub get_line { |
19799a22 |
117 | $thisline = $lookahead; # global variables! |
54310121 |
118 | LINE: while (defined($lookahead = <STDIN>)) { |
a0d0e21e |
119 | if ($lookahead =~ /^[ \t]/) { |
120 | $thisline .= $lookahead; |
121 | } |
122 | else { |
123 | last LINE; |
124 | } |
125 | } |
19799a22 |
126 | return $thisline; |
a0d0e21e |
127 | } |
128 | |
129 | $lookahead = <STDIN>; # get first line |
19799a22 |
130 | while (defined($line = get_line())) { |
a0d0e21e |
131 | ... |
132 | } |
133 | |
09bef843 |
134 | Assigning to a list of private variables to name your arguments: |
a0d0e21e |
135 | |
136 | sub maybeset { |
137 | my($key, $value) = @_; |
cb1a09d0 |
138 | $Foo{$key} = $value unless $Foo{$key}; |
a0d0e21e |
139 | } |
140 | |
19799a22 |
141 | Because the assignment copies the values, this also has the effect |
142 | of turning call-by-reference into call-by-value. Otherwise a |
143 | function is free to do in-place modifications of C<@_> and change |
144 | its caller's values. |
d74e8afc |
145 | X<call-by-reference> X<call-by-value> |
cb1a09d0 |
146 | |
147 | upcase_in($v1, $v2); # this changes $v1 and $v2 |
148 | sub upcase_in { |
54310121 |
149 | for (@_) { tr/a-z/A-Z/ } |
150 | } |
cb1a09d0 |
151 | |
152 | You aren't allowed to modify constants in this way, of course. If an |
153 | argument were actually literal and you tried to change it, you'd take a |
154 | (presumably fatal) exception. For example, this won't work: |
d74e8afc |
155 | X<call-by-reference> X<call-by-value> |
cb1a09d0 |
156 | |
157 | upcase_in("frederick"); |
158 | |
f86cebdf |
159 | It would be much safer if the C<upcase_in()> function |
cb1a09d0 |
160 | were written to return a copy of its parameters instead |
161 | of changing them in place: |
162 | |
19799a22 |
163 | ($v3, $v4) = upcase($v1, $v2); # this doesn't change $v1 and $v2 |
cb1a09d0 |
164 | sub upcase { |
54310121 |
165 | return unless defined wantarray; # void context, do nothing |
cb1a09d0 |
166 | my @parms = @_; |
54310121 |
167 | for (@parms) { tr/a-z/A-Z/ } |
c07a80fd |
168 | return wantarray ? @parms : $parms[0]; |
54310121 |
169 | } |
cb1a09d0 |
170 | |
19799a22 |
171 | Notice how this (unprototyped) function doesn't care whether it was |
a2293a43 |
172 | passed real scalars or arrays. Perl sees all arguments as one big, |
19799a22 |
173 | long, flat parameter list in C<@_>. This is one area where |
174 | Perl's simple argument-passing style shines. The C<upcase()> |
175 | function would work perfectly well without changing the C<upcase()> |
176 | definition even if we fed it things like this: |
cb1a09d0 |
177 | |
178 | @newlist = upcase(@list1, @list2); |
179 | @newlist = upcase( split /:/, $var ); |
180 | |
181 | Do not, however, be tempted to do this: |
182 | |
183 | (@a, @b) = upcase(@list1, @list2); |
184 | |
19799a22 |
185 | Like the flattened incoming parameter list, the return list is also |
186 | flattened on return. So all you have managed to do here is stored |
17b63f68 |
187 | everything in C<@a> and made C<@b> empty. See |
13a2d996 |
188 | L<Pass by Reference> for alternatives. |
19799a22 |
189 | |
190 | A subroutine may be called using an explicit C<&> prefix. The |
191 | C<&> is optional in modern Perl, as are parentheses if the |
192 | subroutine has been predeclared. The C<&> is I<not> optional |
193 | when just naming the subroutine, such as when it's used as |
194 | an argument to defined() or undef(). Nor is it optional when you |
195 | want to do an indirect subroutine call with a subroutine name or |
196 | reference using the C<&$subref()> or C<&{$subref}()> constructs, |
c47ff5f1 |
197 | although the C<< $subref->() >> notation solves that problem. |
19799a22 |
198 | See L<perlref> for more about all that. |
d74e8afc |
199 | X<&> |
19799a22 |
200 | |
201 | Subroutines may be called recursively. If a subroutine is called |
202 | using the C<&> form, the argument list is optional, and if omitted, |
203 | no C<@_> array is set up for the subroutine: the C<@_> array at the |
204 | time of the call is visible to subroutine instead. This is an |
205 | efficiency mechanism that new users may wish to avoid. |
d74e8afc |
206 | X<recursion> |
a0d0e21e |
207 | |
208 | &foo(1,2,3); # pass three arguments |
209 | foo(1,2,3); # the same |
210 | |
211 | foo(); # pass a null list |
212 | &foo(); # the same |
a0d0e21e |
213 | |
cb1a09d0 |
214 | &foo; # foo() get current args, like foo(@_) !! |
54310121 |
215 | foo; # like foo() IFF sub foo predeclared, else "foo" |
cb1a09d0 |
216 | |
19799a22 |
217 | Not only does the C<&> form make the argument list optional, it also |
218 | disables any prototype checking on arguments you do provide. This |
c07a80fd |
219 | is partly for historical reasons, and partly for having a convenient way |
19799a22 |
220 | to cheat if you know what you're doing. See L<Prototypes> below. |
d74e8afc |
221 | X<&> |
c07a80fd |
222 | |
ac90fb77 |
223 | Subroutines whose names are in all upper case are reserved to the Perl |
224 | core, as are modules whose names are in all lower case. A subroutine in |
225 | all capitals is a loosely-held convention meaning it will be called |
226 | indirectly by the run-time system itself, usually due to a triggered event. |
227 | Subroutines that do special, pre-defined things include C<AUTOLOAD>, C<CLONE>, |
228 | C<DESTROY> plus all functions mentioned in L<perltie> and L<PerlIO::via>. |
229 | |
3c10abe3 |
230 | The C<BEGIN>, C<UNITCHECK>, C<CHECK>, C<INIT> and C<END> subroutines |
231 | are not so much subroutines as named special code blocks, of which you |
232 | can have more than one in a package, and which you can B<not> call |
233 | explicitly. See L<perlmod/"BEGIN, UNITCHECK, CHECK, INIT and END"> |
5a964f20 |
234 | |
b687b08b |
235 | =head2 Private Variables via my() |
d74e8afc |
236 | X<my> X<variable, lexical> X<lexical> X<lexical variable> X<scope, lexical> |
237 | X<lexical scope> X<attributes, my> |
cb1a09d0 |
238 | |
239 | Synopsis: |
240 | |
241 | my $foo; # declare $foo lexically local |
242 | my (@wid, %get); # declare list of variables local |
243 | my $foo = "flurp"; # declare $foo lexical, and init it |
244 | my @oof = @bar; # declare @oof lexical, and init it |
09bef843 |
245 | my $x : Foo = $y; # similar, with an attribute applied |
246 | |
a0ae32d3 |
247 | B<WARNING>: The use of attribute lists on C<my> declarations is still |
248 | evolving. The current semantics and interface are subject to change. |
249 | See L<attributes> and L<Attribute::Handlers>. |
cb1a09d0 |
250 | |
19799a22 |
251 | The C<my> operator declares the listed variables to be lexically |
252 | confined to the enclosing block, conditional (C<if/unless/elsif/else>), |
253 | loop (C<for/foreach/while/until/continue>), subroutine, C<eval>, |
254 | or C<do/require/use>'d file. If more than one value is listed, the |
255 | list must be placed in parentheses. All listed elements must be |
256 | legal lvalues. Only alphanumeric identifiers may be lexically |
325192b1 |
257 | scoped--magical built-ins like C<$/> must currently be C<local>ized |
19799a22 |
258 | with C<local> instead. |
259 | |
260 | Unlike dynamic variables created by the C<local> operator, lexical |
261 | variables declared with C<my> are totally hidden from the outside |
262 | world, including any called subroutines. This is true if it's the |
263 | same subroutine called from itself or elsewhere--every call gets |
264 | its own copy. |
d74e8afc |
265 | X<local> |
19799a22 |
266 | |
267 | This doesn't mean that a C<my> variable declared in a statically |
268 | enclosing lexical scope would be invisible. Only dynamic scopes |
269 | are cut off. For example, the C<bumpx()> function below has access |
270 | to the lexical $x variable because both the C<my> and the C<sub> |
271 | occurred at the same scope, presumably file scope. |
5a964f20 |
272 | |
273 | my $x = 10; |
274 | sub bumpx { $x++ } |
275 | |
19799a22 |
276 | An C<eval()>, however, can see lexical variables of the scope it is |
277 | being evaluated in, so long as the names aren't hidden by declarations within |
278 | the C<eval()> itself. See L<perlref>. |
d74e8afc |
279 | X<eval, scope of> |
cb1a09d0 |
280 | |
19799a22 |
281 | The parameter list to my() may be assigned to if desired, which allows you |
cb1a09d0 |
282 | to initialize your variables. (If no initializer is given for a |
283 | particular variable, it is created with the undefined value.) Commonly |
19799a22 |
284 | this is used to name input parameters to a subroutine. Examples: |
cb1a09d0 |
285 | |
286 | $arg = "fred"; # "global" variable |
287 | $n = cube_root(27); |
288 | print "$arg thinks the root is $n\n"; |
289 | fred thinks the root is 3 |
290 | |
291 | sub cube_root { |
292 | my $arg = shift; # name doesn't matter |
293 | $arg **= 1/3; |
294 | return $arg; |
54310121 |
295 | } |
cb1a09d0 |
296 | |
19799a22 |
297 | The C<my> is simply a modifier on something you might assign to. So when |
298 | you do assign to variables in its argument list, C<my> doesn't |
6cc33c6d |
299 | change whether those variables are viewed as a scalar or an array. So |
cb1a09d0 |
300 | |
5a964f20 |
301 | my ($foo) = <STDIN>; # WRONG? |
cb1a09d0 |
302 | my @FOO = <STDIN>; |
303 | |
5f05dabc |
304 | both supply a list context to the right-hand side, while |
cb1a09d0 |
305 | |
306 | my $foo = <STDIN>; |
307 | |
5f05dabc |
308 | supplies a scalar context. But the following declares only one variable: |
748a9306 |
309 | |
5a964f20 |
310 | my $foo, $bar = 1; # WRONG |
748a9306 |
311 | |
cb1a09d0 |
312 | That has the same effect as |
748a9306 |
313 | |
cb1a09d0 |
314 | my $foo; |
315 | $bar = 1; |
a0d0e21e |
316 | |
cb1a09d0 |
317 | The declared variable is not introduced (is not visible) until after |
318 | the current statement. Thus, |
319 | |
320 | my $x = $x; |
321 | |
19799a22 |
322 | can be used to initialize a new $x with the value of the old $x, and |
cb1a09d0 |
323 | the expression |
324 | |
325 | my $x = 123 and $x == 123 |
326 | |
19799a22 |
327 | is false unless the old $x happened to have the value C<123>. |
cb1a09d0 |
328 | |
55497cff |
329 | Lexical scopes of control structures are not bounded precisely by the |
330 | braces that delimit their controlled blocks; control expressions are |
19799a22 |
331 | part of that scope, too. Thus in the loop |
55497cff |
332 | |
19799a22 |
333 | while (my $line = <>) { |
55497cff |
334 | $line = lc $line; |
335 | } continue { |
336 | print $line; |
337 | } |
338 | |
19799a22 |
339 | the scope of $line extends from its declaration throughout the rest of |
55497cff |
340 | the loop construct (including the C<continue> clause), but not beyond |
341 | it. Similarly, in the conditional |
342 | |
343 | if ((my $answer = <STDIN>) =~ /^yes$/i) { |
344 | user_agrees(); |
345 | } elsif ($answer =~ /^no$/i) { |
346 | user_disagrees(); |
347 | } else { |
348 | chomp $answer; |
349 | die "'$answer' is neither 'yes' nor 'no'"; |
350 | } |
351 | |
19799a22 |
352 | the scope of $answer extends from its declaration through the rest |
353 | of that conditional, including any C<elsif> and C<else> clauses, |
457b36cb |
354 | but not beyond it. See L<perlsyn/"Simple statements"> for information |
355 | on the scope of variables in statements with modifiers. |
55497cff |
356 | |
5f05dabc |
357 | The C<foreach> loop defaults to scoping its index variable dynamically |
19799a22 |
358 | in the manner of C<local>. However, if the index variable is |
359 | prefixed with the keyword C<my>, or if there is already a lexical |
360 | by that name in scope, then a new lexical is created instead. Thus |
361 | in the loop |
d74e8afc |
362 | X<foreach> X<for> |
55497cff |
363 | |
364 | for my $i (1, 2, 3) { |
365 | some_function(); |
366 | } |
367 | |
19799a22 |
368 | the scope of $i extends to the end of the loop, but not beyond it, |
369 | rendering the value of $i inaccessible within C<some_function()>. |
d74e8afc |
370 | X<foreach> X<for> |
55497cff |
371 | |
cb1a09d0 |
372 | Some users may wish to encourage the use of lexically scoped variables. |
19799a22 |
373 | As an aid to catching implicit uses to package variables, |
374 | which are always global, if you say |
cb1a09d0 |
375 | |
376 | use strict 'vars'; |
377 | |
19799a22 |
378 | then any variable mentioned from there to the end of the enclosing |
379 | block must either refer to a lexical variable, be predeclared via |
77ca0c92 |
380 | C<our> or C<use vars>, or else must be fully qualified with the package name. |
19799a22 |
381 | A compilation error results otherwise. An inner block may countermand |
382 | this with C<no strict 'vars'>. |
383 | |
384 | A C<my> has both a compile-time and a run-time effect. At compile |
8593bda5 |
385 | time, the compiler takes notice of it. The principal usefulness |
19799a22 |
386 | of this is to quiet C<use strict 'vars'>, but it is also essential |
387 | for generation of closures as detailed in L<perlref>. Actual |
388 | initialization is delayed until run time, though, so it gets executed |
389 | at the appropriate time, such as each time through a loop, for |
390 | example. |
391 | |
392 | Variables declared with C<my> are not part of any package and are therefore |
cb1a09d0 |
393 | never fully qualified with the package name. In particular, you're not |
394 | allowed to try to make a package variable (or other global) lexical: |
395 | |
396 | my $pack::var; # ERROR! Illegal syntax |
cb1a09d0 |
397 | |
398 | In fact, a dynamic variable (also known as package or global variables) |
f86cebdf |
399 | are still accessible using the fully qualified C<::> notation even while a |
cb1a09d0 |
400 | lexical of the same name is also visible: |
401 | |
402 | package main; |
403 | local $x = 10; |
404 | my $x = 20; |
405 | print "$x and $::x\n"; |
406 | |
f86cebdf |
407 | That will print out C<20> and C<10>. |
cb1a09d0 |
408 | |
19799a22 |
409 | You may declare C<my> variables at the outermost scope of a file |
410 | to hide any such identifiers from the world outside that file. This |
411 | is similar in spirit to C's static variables when they are used at |
412 | the file level. To do this with a subroutine requires the use of |
413 | a closure (an anonymous function that accesses enclosing lexicals). |
414 | If you want to create a private subroutine that cannot be called |
415 | from outside that block, it can declare a lexical variable containing |
416 | an anonymous sub reference: |
cb1a09d0 |
417 | |
418 | my $secret_version = '1.001-beta'; |
419 | my $secret_sub = sub { print $secret_version }; |
420 | &$secret_sub(); |
421 | |
422 | As long as the reference is never returned by any function within the |
5f05dabc |
423 | module, no outside module can see the subroutine, because its name is not in |
cb1a09d0 |
424 | any package's symbol table. Remember that it's not I<REALLY> called |
19799a22 |
425 | C<$some_pack::secret_version> or anything; it's just $secret_version, |
cb1a09d0 |
426 | unqualified and unqualifiable. |
427 | |
19799a22 |
428 | This does not work with object methods, however; all object methods |
429 | have to be in the symbol table of some package to be found. See |
430 | L<perlref/"Function Templates"> for something of a work-around to |
431 | this. |
cb1a09d0 |
432 | |
c2611fb3 |
433 | =head2 Persistent Private Variables |
ba1f8e91 |
434 | X<state> X<state variable> X<static> X<variable, persistent> X<variable, static> X<closure> |
435 | |
436 | There are two ways to build persistent private variables in Perl 5.10. |
437 | First, you can simply use the C<state> feature. Or, you can use closures, |
438 | if you want to stay compatible with releases older than 5.10. |
439 | |
440 | =head3 Persistent variables via state() |
441 | |
442 | Beginning with perl 5.9.4, you can declare variables with the C<state> |
443 | keyword in place of C<my>. For that to work, though, you must have |
444 | enabled that feature beforehand, either by using the C<feature> pragma, or |
445 | by using C<-E> on one-liners. (see L<feature>) |
446 | |
447 | For example, the following code maintains a private counter, incremented |
448 | each time the gimme_another() function is called: |
449 | |
450 | use feature 'state'; |
451 | sub gimme_another { state $x; return ++$x } |
452 | |
453 | Also, since C<$x> is lexical, it can't be reached or modified by any Perl |
454 | code outside. |
455 | |
456 | You can initialize state variables, and the assigment will be executed |
457 | only once: |
458 | |
459 | sub starts_from_42 { state $x = 42; return ++$x } |
460 | |
461 | You can also, as a syntactic shortcut, initialize more than one if they're |
462 | all declared within the same state() clause: |
463 | |
464 | state ($a, $b, $c) = ( 'one', 'two', 'three' ); |
465 | |
466 | However, be warned that state variables declared as part of a list will |
467 | get assigned each time the statement will be executed, since it will be |
468 | considered as a regular list assigment, not one to be executed only once: |
469 | |
470 | (state $x, my $y) = (1, 2); # $x gets reinitialized every time ! |
471 | |
472 | B<Caveat>: the code at the right side of the assignment to a state |
473 | variable will be executed every time; only the assignment is disabled. So, |
474 | avoid code that has side-effects, or that is slow to execute. This might |
475 | be optimized out in a future version of Perl. |
476 | |
477 | =head3 Persistent variables with closures |
5a964f20 |
478 | |
479 | Just because a lexical variable is lexically (also called statically) |
f86cebdf |
480 | scoped to its enclosing block, C<eval>, or C<do> FILE, this doesn't mean that |
5a964f20 |
481 | within a function it works like a C static. It normally works more |
482 | like a C auto, but with implicit garbage collection. |
483 | |
484 | Unlike local variables in C or C++, Perl's lexical variables don't |
485 | necessarily get recycled just because their scope has exited. |
486 | If something more permanent is still aware of the lexical, it will |
487 | stick around. So long as something else references a lexical, that |
488 | lexical won't be freed--which is as it should be. You wouldn't want |
489 | memory being free until you were done using it, or kept around once you |
490 | were done. Automatic garbage collection takes care of this for you. |
491 | |
492 | This means that you can pass back or save away references to lexical |
493 | variables, whereas to return a pointer to a C auto is a grave error. |
494 | It also gives us a way to simulate C's function statics. Here's a |
495 | mechanism for giving a function private variables with both lexical |
496 | scoping and a static lifetime. If you do want to create something like |
497 | C's static variables, just enclose the whole function in an extra block, |
498 | and put the static variable outside the function but in the block. |
cb1a09d0 |
499 | |
500 | { |
54310121 |
501 | my $secret_val = 0; |
cb1a09d0 |
502 | sub gimme_another { |
503 | return ++$secret_val; |
54310121 |
504 | } |
505 | } |
cb1a09d0 |
506 | # $secret_val now becomes unreachable by the outside |
507 | # world, but retains its value between calls to gimme_another |
508 | |
54310121 |
509 | If this function is being sourced in from a separate file |
cb1a09d0 |
510 | via C<require> or C<use>, then this is probably just fine. If it's |
19799a22 |
511 | all in the main program, you'll need to arrange for the C<my> |
cb1a09d0 |
512 | to be executed early, either by putting the whole block above |
f86cebdf |
513 | your main program, or more likely, placing merely a C<BEGIN> |
ac90fb77 |
514 | code block around it to make sure it gets executed before your program |
cb1a09d0 |
515 | starts to run: |
516 | |
ac90fb77 |
517 | BEGIN { |
54310121 |
518 | my $secret_val = 0; |
cb1a09d0 |
519 | sub gimme_another { |
520 | return ++$secret_val; |
54310121 |
521 | } |
522 | } |
cb1a09d0 |
523 | |
3c10abe3 |
524 | See L<perlmod/"BEGIN, UNITCHECK, CHECK, INIT and END"> about the |
525 | special triggered code blocks, C<BEGIN>, C<UNITCHECK>, C<CHECK>, |
526 | C<INIT> and C<END>. |
cb1a09d0 |
527 | |
19799a22 |
528 | If declared at the outermost scope (the file scope), then lexicals |
529 | work somewhat like C's file statics. They are available to all |
530 | functions in that same file declared below them, but are inaccessible |
531 | from outside that file. This strategy is sometimes used in modules |
532 | to create private variables that the whole module can see. |
5a964f20 |
533 | |
cb1a09d0 |
534 | =head2 Temporary Values via local() |
d74e8afc |
535 | X<local> X<scope, dynamic> X<dynamic scope> X<variable, local> |
536 | X<variable, temporary> |
cb1a09d0 |
537 | |
19799a22 |
538 | B<WARNING>: In general, you should be using C<my> instead of C<local>, because |
6d28dffb |
539 | it's faster and safer. Exceptions to this include the global punctuation |
325192b1 |
540 | variables, global filehandles and formats, and direct manipulation of the |
541 | Perl symbol table itself. C<local> is mostly used when the current value |
542 | of a variable must be visible to called subroutines. |
cb1a09d0 |
543 | |
544 | Synopsis: |
545 | |
325192b1 |
546 | # localization of values |
547 | |
548 | local $foo; # make $foo dynamically local |
549 | local (@wid, %get); # make list of variables local |
550 | local $foo = "flurp"; # make $foo dynamic, and init it |
551 | local @oof = @bar; # make @oof dynamic, and init it |
552 | |
553 | local $hash{key} = "val"; # sets a local value for this hash entry |
554 | local ($cond ? $v1 : $v2); # several types of lvalues support |
555 | # localization |
556 | |
557 | # localization of symbols |
cb1a09d0 |
558 | |
559 | local *FH; # localize $FH, @FH, %FH, &FH ... |
560 | local *merlyn = *randal; # now $merlyn is really $randal, plus |
561 | # @merlyn is really @randal, etc |
562 | local *merlyn = 'randal'; # SAME THING: promote 'randal' to *randal |
54310121 |
563 | local *merlyn = \$randal; # just alias $merlyn, not @merlyn etc |
cb1a09d0 |
564 | |
19799a22 |
565 | A C<local> modifies its listed variables to be "local" to the |
566 | enclosing block, C<eval>, or C<do FILE>--and to I<any subroutine |
567 | called from within that block>. A C<local> just gives temporary |
568 | values to global (meaning package) variables. It does I<not> create |
569 | a local variable. This is known as dynamic scoping. Lexical scoping |
570 | is done with C<my>, which works more like C's auto declarations. |
cb1a09d0 |
571 | |
325192b1 |
572 | Some types of lvalues can be localized as well : hash and array elements |
573 | and slices, conditionals (provided that their result is always |
574 | localizable), and symbolic references. As for simple variables, this |
575 | creates new, dynamically scoped values. |
576 | |
577 | If more than one variable or expression is given to C<local>, they must be |
578 | placed in parentheses. This operator works |
cb1a09d0 |
579 | by saving the current values of those variables in its argument list on a |
5f05dabc |
580 | hidden stack and restoring them upon exiting the block, subroutine, or |
cb1a09d0 |
581 | eval. This means that called subroutines can also reference the local |
582 | variable, but not the global one. The argument list may be assigned to if |
583 | desired, which allows you to initialize your local variables. (If no |
584 | initializer is given for a particular variable, it is created with an |
325192b1 |
585 | undefined value.) |
cb1a09d0 |
586 | |
19799a22 |
587 | Because C<local> is a run-time operator, it gets executed each time |
325192b1 |
588 | through a loop. Consequently, it's more efficient to localize your |
589 | variables outside the loop. |
590 | |
591 | =head3 Grammatical note on local() |
d74e8afc |
592 | X<local, context> |
cb1a09d0 |
593 | |
f86cebdf |
594 | A C<local> is simply a modifier on an lvalue expression. When you assign to |
595 | a C<local>ized variable, the C<local> doesn't change whether its list is viewed |
cb1a09d0 |
596 | as a scalar or an array. So |
597 | |
598 | local($foo) = <STDIN>; |
599 | local @FOO = <STDIN>; |
600 | |
5f05dabc |
601 | both supply a list context to the right-hand side, while |
cb1a09d0 |
602 | |
603 | local $foo = <STDIN>; |
604 | |
605 | supplies a scalar context. |
606 | |
325192b1 |
607 | =head3 Localization of special variables |
d74e8afc |
608 | X<local, special variable> |
3e3baf6d |
609 | |
325192b1 |
610 | If you localize a special variable, you'll be giving a new value to it, |
611 | but its magic won't go away. That means that all side-effects related |
612 | to this magic still work with the localized value. |
3e3baf6d |
613 | |
325192b1 |
614 | This feature allows code like this to work : |
615 | |
616 | # Read the whole contents of FILE in $slurp |
617 | { local $/ = undef; $slurp = <FILE>; } |
618 | |
619 | Note, however, that this restricts localization of some values ; for |
620 | example, the following statement dies, as of perl 5.9.0, with an error |
621 | I<Modification of a read-only value attempted>, because the $1 variable is |
622 | magical and read-only : |
623 | |
624 | local $1 = 2; |
625 | |
626 | Similarly, but in a way more difficult to spot, the following snippet will |
627 | die in perl 5.9.0 : |
628 | |
629 | sub f { local $_ = "foo"; print } |
630 | for ($1) { |
631 | # now $_ is aliased to $1, thus is magic and readonly |
632 | f(); |
3e3baf6d |
633 | } |
3e3baf6d |
634 | |
325192b1 |
635 | See next section for an alternative to this situation. |
636 | |
637 | B<WARNING>: Localization of tied arrays and hashes does not currently |
638 | work as described. |
fd5a896a |
639 | This will be fixed in a future release of Perl; in the meantime, avoid |
640 | code that relies on any particular behaviour of localising tied arrays |
641 | or hashes (localising individual elements is still okay). |
325192b1 |
642 | See L<perl58delta/"Localising Tied Arrays and Hashes Is Broken"> for more |
fd5a896a |
643 | details. |
d74e8afc |
644 | X<local, tie> |
fd5a896a |
645 | |
325192b1 |
646 | =head3 Localization of globs |
d74e8afc |
647 | X<local, glob> X<glob> |
3e3baf6d |
648 | |
325192b1 |
649 | The construct |
650 | |
651 | local *name; |
652 | |
653 | creates a whole new symbol table entry for the glob C<name> in the |
654 | current package. That means that all variables in its glob slot ($name, |
655 | @name, %name, &name, and the C<name> filehandle) are dynamically reset. |
656 | |
657 | This implies, among other things, that any magic eventually carried by |
658 | those variables is locally lost. In other words, saying C<local */> |
659 | will not have any effect on the internal value of the input record |
660 | separator. |
661 | |
662 | Notably, if you want to work with a brand new value of the default scalar |
663 | $_, and avoid the potential problem listed above about $_ previously |
664 | carrying a magic value, you should use C<local *_> instead of C<local $_>. |
a4fb8298 |
665 | As of perl 5.9.1, you can also use the lexical form of C<$_> (declaring it |
666 | with C<my $_>), which avoids completely this problem. |
325192b1 |
667 | |
668 | =head3 Localization of elements of composite types |
d74e8afc |
669 | X<local, composite type element> X<local, array element> X<local, hash element> |
3e3baf6d |
670 | |
6ee623d5 |
671 | It's also worth taking a moment to explain what happens when you |
f86cebdf |
672 | C<local>ize a member of a composite type (i.e. an array or hash element). |
673 | In this case, the element is C<local>ized I<by name>. This means that |
6ee623d5 |
674 | when the scope of the C<local()> ends, the saved value will be |
675 | restored to the hash element whose key was named in the C<local()>, or |
676 | the array element whose index was named in the C<local()>. If that |
677 | element was deleted while the C<local()> was in effect (e.g. by a |
678 | C<delete()> from a hash or a C<shift()> of an array), it will spring |
679 | back into existence, possibly extending an array and filling in the |
680 | skipped elements with C<undef>. For instance, if you say |
681 | |
682 | %hash = ( 'This' => 'is', 'a' => 'test' ); |
683 | @ary = ( 0..5 ); |
684 | { |
685 | local($ary[5]) = 6; |
686 | local($hash{'a'}) = 'drill'; |
687 | while (my $e = pop(@ary)) { |
688 | print "$e . . .\n"; |
689 | last unless $e > 3; |
690 | } |
691 | if (@ary) { |
692 | $hash{'only a'} = 'test'; |
693 | delete $hash{'a'}; |
694 | } |
695 | } |
696 | print join(' ', map { "$_ $hash{$_}" } sort keys %hash),".\n"; |
697 | print "The array has ",scalar(@ary)," elements: ", |
698 | join(', ', map { defined $_ ? $_ : 'undef' } @ary),"\n"; |
699 | |
700 | Perl will print |
701 | |
702 | 6 . . . |
703 | 4 . . . |
704 | 3 . . . |
705 | This is a test only a test. |
706 | The array has 6 elements: 0, 1, 2, undef, undef, 5 |
707 | |
19799a22 |
708 | The behavior of local() on non-existent members of composite |
7185e5cc |
709 | types is subject to change in future. |
710 | |
cd06dffe |
711 | =head2 Lvalue subroutines |
d74e8afc |
712 | X<lvalue> X<subroutine, lvalue> |
cd06dffe |
713 | |
e6a32221 |
714 | B<WARNING>: Lvalue subroutines are still experimental and the |
715 | implementation may change in future versions of Perl. |
cd06dffe |
716 | |
717 | It is possible to return a modifiable value from a subroutine. |
718 | To do this, you have to declare the subroutine to return an lvalue. |
719 | |
720 | my $val; |
721 | sub canmod : lvalue { |
e6a32221 |
722 | # return $val; this doesn't work, don't say "return" |
cd06dffe |
723 | $val; |
724 | } |
725 | sub nomod { |
726 | $val; |
727 | } |
728 | |
729 | canmod() = 5; # assigns to $val |
730 | nomod() = 5; # ERROR |
731 | |
732 | The scalar/list context for the subroutine and for the right-hand |
733 | side of assignment is determined as if the subroutine call is replaced |
734 | by a scalar. For example, consider: |
735 | |
736 | data(2,3) = get_data(3,4); |
737 | |
738 | Both subroutines here are called in a scalar context, while in: |
739 | |
740 | (data(2,3)) = get_data(3,4); |
741 | |
742 | and in: |
743 | |
744 | (data(2),data(3)) = get_data(3,4); |
745 | |
746 | all the subroutines are called in a list context. |
747 | |
e6a32221 |
748 | =over 4 |
749 | |
750 | =item Lvalue subroutines are EXPERIMENTAL |
751 | |
752 | They appear to be convenient, but there are several reasons to be |
753 | circumspect. |
754 | |
755 | You can't use the return keyword, you must pass out the value before |
756 | falling out of subroutine scope. (see comment in example above). This |
757 | is usually not a problem, but it disallows an explicit return out of a |
758 | deeply nested loop, which is sometimes a nice way out. |
759 | |
760 | They violate encapsulation. A normal mutator can check the supplied |
761 | argument before setting the attribute it is protecting, an lvalue |
762 | subroutine never gets that chance. Consider; |
763 | |
764 | my $some_array_ref = []; # protected by mutators ?? |
765 | |
766 | sub set_arr { # normal mutator |
767 | my $val = shift; |
768 | die("expected array, you supplied ", ref $val) |
769 | unless ref $val eq 'ARRAY'; |
770 | $some_array_ref = $val; |
771 | } |
772 | sub set_arr_lv : lvalue { # lvalue mutator |
773 | $some_array_ref; |
774 | } |
775 | |
776 | # set_arr_lv cannot stop this ! |
777 | set_arr_lv() = { a => 1 }; |
818c4caa |
778 | |
e6a32221 |
779 | =back |
780 | |
cb1a09d0 |
781 | =head2 Passing Symbol Table Entries (typeglobs) |
d74e8afc |
782 | X<typeglob> X<*> |
cb1a09d0 |
783 | |
19799a22 |
784 | B<WARNING>: The mechanism described in this section was originally |
785 | the only way to simulate pass-by-reference in older versions of |
786 | Perl. While it still works fine in modern versions, the new reference |
787 | mechanism is generally easier to work with. See below. |
a0d0e21e |
788 | |
789 | Sometimes you don't want to pass the value of an array to a subroutine |
790 | but rather the name of it, so that the subroutine can modify the global |
791 | copy of it rather than working with a local copy. In perl you can |
cb1a09d0 |
792 | refer to all objects of a particular name by prefixing the name |
5f05dabc |
793 | with a star: C<*foo>. This is often known as a "typeglob", because the |
a0d0e21e |
794 | star on the front can be thought of as a wildcard match for all the |
795 | funny prefix characters on variables and subroutines and such. |
796 | |
55497cff |
797 | When evaluated, the typeglob produces a scalar value that represents |
5f05dabc |
798 | all the objects of that name, including any filehandle, format, or |
a0d0e21e |
799 | subroutine. When assigned to, it causes the name mentioned to refer to |
19799a22 |
800 | whatever C<*> value was assigned to it. Example: |
a0d0e21e |
801 | |
802 | sub doubleary { |
803 | local(*someary) = @_; |
804 | foreach $elem (@someary) { |
805 | $elem *= 2; |
806 | } |
807 | } |
808 | doubleary(*foo); |
809 | doubleary(*bar); |
810 | |
19799a22 |
811 | Scalars are already passed by reference, so you can modify |
a0d0e21e |
812 | scalar arguments without using this mechanism by referring explicitly |
1fef88e7 |
813 | to C<$_[0]> etc. You can modify all the elements of an array by passing |
f86cebdf |
814 | all the elements as scalars, but you have to use the C<*> mechanism (or |
815 | the equivalent reference mechanism) to C<push>, C<pop>, or change the size of |
a0d0e21e |
816 | an array. It will certainly be faster to pass the typeglob (or reference). |
817 | |
818 | Even if you don't want to modify an array, this mechanism is useful for |
5f05dabc |
819 | passing multiple arrays in a single LIST, because normally the LIST |
a0d0e21e |
820 | mechanism will merge all the array values so that you can't extract out |
55497cff |
821 | the individual arrays. For more on typeglobs, see |
2ae324a7 |
822 | L<perldata/"Typeglobs and Filehandles">. |
cb1a09d0 |
823 | |
5a964f20 |
824 | =head2 When to Still Use local() |
d74e8afc |
825 | X<local> X<variable, local> |
5a964f20 |
826 | |
19799a22 |
827 | Despite the existence of C<my>, there are still three places where the |
828 | C<local> operator still shines. In fact, in these three places, you |
5a964f20 |
829 | I<must> use C<local> instead of C<my>. |
830 | |
13a2d996 |
831 | =over 4 |
5a964f20 |
832 | |
551e1d92 |
833 | =item 1. |
834 | |
835 | You need to give a global variable a temporary value, especially $_. |
5a964f20 |
836 | |
f86cebdf |
837 | The global variables, like C<@ARGV> or the punctuation variables, must be |
838 | C<local>ized with C<local()>. This block reads in F</etc/motd>, and splits |
5a964f20 |
839 | it up into chunks separated by lines of equal signs, which are placed |
f86cebdf |
840 | in C<@Fields>. |
5a964f20 |
841 | |
842 | { |
843 | local @ARGV = ("/etc/motd"); |
844 | local $/ = undef; |
845 | local $_ = <>; |
846 | @Fields = split /^\s*=+\s*$/; |
847 | } |
848 | |
19799a22 |
849 | It particular, it's important to C<local>ize $_ in any routine that assigns |
5a964f20 |
850 | to it. Look out for implicit assignments in C<while> conditionals. |
851 | |
551e1d92 |
852 | =item 2. |
853 | |
854 | You need to create a local file or directory handle or a local function. |
5a964f20 |
855 | |
09bef843 |
856 | A function that needs a filehandle of its own must use |
857 | C<local()> on a complete typeglob. This can be used to create new symbol |
5a964f20 |
858 | table entries: |
859 | |
860 | sub ioqueue { |
861 | local (*READER, *WRITER); # not my! |
17b63f68 |
862 | pipe (READER, WRITER) or die "pipe: $!"; |
5a964f20 |
863 | return (*READER, *WRITER); |
864 | } |
865 | ($head, $tail) = ioqueue(); |
866 | |
867 | See the Symbol module for a way to create anonymous symbol table |
868 | entries. |
869 | |
870 | Because assignment of a reference to a typeglob creates an alias, this |
871 | can be used to create what is effectively a local function, or at least, |
872 | a local alias. |
873 | |
874 | { |
f86cebdf |
875 | local *grow = \&shrink; # only until this block exists |
876 | grow(); # really calls shrink() |
877 | move(); # if move() grow()s, it shrink()s too |
5a964f20 |
878 | } |
f86cebdf |
879 | grow(); # get the real grow() again |
5a964f20 |
880 | |
881 | See L<perlref/"Function Templates"> for more about manipulating |
882 | functions by name in this way. |
883 | |
551e1d92 |
884 | =item 3. |
885 | |
886 | You want to temporarily change just one element of an array or hash. |
5a964f20 |
887 | |
f86cebdf |
888 | You can C<local>ize just one element of an aggregate. Usually this |
5a964f20 |
889 | is done on dynamics: |
890 | |
891 | { |
892 | local $SIG{INT} = 'IGNORE'; |
893 | funct(); # uninterruptible |
894 | } |
895 | # interruptibility automatically restored here |
896 | |
897 | But it also works on lexically declared aggregates. Prior to 5.005, |
898 | this operation could on occasion misbehave. |
899 | |
900 | =back |
901 | |
cb1a09d0 |
902 | =head2 Pass by Reference |
d74e8afc |
903 | X<pass by reference> X<pass-by-reference> X<reference> |
cb1a09d0 |
904 | |
55497cff |
905 | If you want to pass more than one array or hash into a function--or |
906 | return them from it--and have them maintain their integrity, then |
907 | you're going to have to use an explicit pass-by-reference. Before you |
908 | do that, you need to understand references as detailed in L<perlref>. |
c07a80fd |
909 | This section may not make much sense to you otherwise. |
cb1a09d0 |
910 | |
19799a22 |
911 | Here are a few simple examples. First, let's pass in several arrays |
912 | to a function and have it C<pop> all of then, returning a new list |
913 | of all their former last elements: |
cb1a09d0 |
914 | |
915 | @tailings = popmany ( \@a, \@b, \@c, \@d ); |
916 | |
917 | sub popmany { |
918 | my $aref; |
919 | my @retlist = (); |
920 | foreach $aref ( @_ ) { |
921 | push @retlist, pop @$aref; |
54310121 |
922 | } |
cb1a09d0 |
923 | return @retlist; |
54310121 |
924 | } |
cb1a09d0 |
925 | |
54310121 |
926 | Here's how you might write a function that returns a |
cb1a09d0 |
927 | list of keys occurring in all the hashes passed to it: |
928 | |
54310121 |
929 | @common = inter( \%foo, \%bar, \%joe ); |
cb1a09d0 |
930 | sub inter { |
931 | my ($k, $href, %seen); # locals |
932 | foreach $href (@_) { |
933 | while ( $k = each %$href ) { |
934 | $seen{$k}++; |
54310121 |
935 | } |
936 | } |
cb1a09d0 |
937 | return grep { $seen{$_} == @_ } keys %seen; |
54310121 |
938 | } |
cb1a09d0 |
939 | |
5f05dabc |
940 | So far, we're using just the normal list return mechanism. |
54310121 |
941 | What happens if you want to pass or return a hash? Well, |
942 | if you're using only one of them, or you don't mind them |
cb1a09d0 |
943 | concatenating, then the normal calling convention is ok, although |
54310121 |
944 | a little expensive. |
cb1a09d0 |
945 | |
946 | Where people get into trouble is here: |
947 | |
948 | (@a, @b) = func(@c, @d); |
949 | or |
950 | (%a, %b) = func(%c, %d); |
951 | |
19799a22 |
952 | That syntax simply won't work. It sets just C<@a> or C<%a> and |
953 | clears the C<@b> or C<%b>. Plus the function didn't get passed |
954 | into two separate arrays or hashes: it got one long list in C<@_>, |
955 | as always. |
cb1a09d0 |
956 | |
957 | If you can arrange for everyone to deal with this through references, it's |
958 | cleaner code, although not so nice to look at. Here's a function that |
959 | takes two array references as arguments, returning the two array elements |
960 | in order of how many elements they have in them: |
961 | |
962 | ($aref, $bref) = func(\@c, \@d); |
963 | print "@$aref has more than @$bref\n"; |
964 | sub func { |
965 | my ($cref, $dref) = @_; |
966 | if (@$cref > @$dref) { |
967 | return ($cref, $dref); |
968 | } else { |
c07a80fd |
969 | return ($dref, $cref); |
54310121 |
970 | } |
971 | } |
cb1a09d0 |
972 | |
973 | It turns out that you can actually do this also: |
974 | |
975 | (*a, *b) = func(\@c, \@d); |
976 | print "@a has more than @b\n"; |
977 | sub func { |
978 | local (*c, *d) = @_; |
979 | if (@c > @d) { |
980 | return (\@c, \@d); |
981 | } else { |
982 | return (\@d, \@c); |
54310121 |
983 | } |
984 | } |
cb1a09d0 |
985 | |
986 | Here we're using the typeglobs to do symbol table aliasing. It's |
19799a22 |
987 | a tad subtle, though, and also won't work if you're using C<my> |
09bef843 |
988 | variables, because only globals (even in disguise as C<local>s) |
19799a22 |
989 | are in the symbol table. |
5f05dabc |
990 | |
991 | If you're passing around filehandles, you could usually just use the bare |
19799a22 |
992 | typeglob, like C<*STDOUT>, but typeglobs references work, too. |
993 | For example: |
5f05dabc |
994 | |
995 | splutter(\*STDOUT); |
996 | sub splutter { |
997 | my $fh = shift; |
998 | print $fh "her um well a hmmm\n"; |
999 | } |
1000 | |
1001 | $rec = get_rec(\*STDIN); |
1002 | sub get_rec { |
1003 | my $fh = shift; |
1004 | return scalar <$fh>; |
1005 | } |
1006 | |
19799a22 |
1007 | If you're planning on generating new filehandles, you could do this. |
1008 | Notice to pass back just the bare *FH, not its reference. |
5f05dabc |
1009 | |
1010 | sub openit { |
19799a22 |
1011 | my $path = shift; |
5f05dabc |
1012 | local *FH; |
e05a3a1e |
1013 | return open (FH, $path) ? *FH : undef; |
54310121 |
1014 | } |
5f05dabc |
1015 | |
cb1a09d0 |
1016 | =head2 Prototypes |
d74e8afc |
1017 | X<prototype> X<subroutine, prototype> |
cb1a09d0 |
1018 | |
19799a22 |
1019 | Perl supports a very limited kind of compile-time argument checking |
1020 | using function prototyping. If you declare |
cb1a09d0 |
1021 | |
1022 | sub mypush (\@@) |
1023 | |
19799a22 |
1024 | then C<mypush()> takes arguments exactly like C<push()> does. The |
1025 | function declaration must be visible at compile time. The prototype |
1026 | affects only interpretation of new-style calls to the function, |
1027 | where new-style is defined as not using the C<&> character. In |
1028 | other words, if you call it like a built-in function, then it behaves |
1029 | like a built-in function. If you call it like an old-fashioned |
1030 | subroutine, then it behaves like an old-fashioned subroutine. It |
1031 | naturally falls out from this rule that prototypes have no influence |
1032 | on subroutine references like C<\&foo> or on indirect subroutine |
c47ff5f1 |
1033 | calls like C<&{$subref}> or C<< $subref->() >>. |
c07a80fd |
1034 | |
1035 | Method calls are not influenced by prototypes either, because the |
19799a22 |
1036 | function to be called is indeterminate at compile time, since |
1037 | the exact code called depends on inheritance. |
cb1a09d0 |
1038 | |
19799a22 |
1039 | Because the intent of this feature is primarily to let you define |
1040 | subroutines that work like built-in functions, here are prototypes |
1041 | for some other functions that parse almost exactly like the |
1042 | corresponding built-in. |
cb1a09d0 |
1043 | |
1044 | Declared as Called as |
1045 | |
f86cebdf |
1046 | sub mylink ($$) mylink $old, $new |
1047 | sub myvec ($$$) myvec $var, $offset, 1 |
1048 | sub myindex ($$;$) myindex &getstring, "substr" |
1049 | sub mysyswrite ($$$;$) mysyswrite $buf, 0, length($buf) - $off, $off |
1050 | sub myreverse (@) myreverse $a, $b, $c |
1051 | sub myjoin ($@) myjoin ":", $a, $b, $c |
1052 | sub mypop (\@) mypop @array |
1053 | sub mysplice (\@$$@) mysplice @array, @array, 0, @pushme |
1054 | sub mykeys (\%) mykeys %{$hashref} |
1055 | sub myopen (*;$) myopen HANDLE, $name |
1056 | sub mypipe (**) mypipe READHANDLE, WRITEHANDLE |
1057 | sub mygrep (&@) mygrep { /foo/ } $a, $b, $c |
d822fdf9 |
1058 | sub myrand (;$) myrand 42 |
f86cebdf |
1059 | sub mytime () mytime |
cb1a09d0 |
1060 | |
c07a80fd |
1061 | Any backslashed prototype character represents an actual argument |
6e47f808 |
1062 | that absolutely must start with that character. The value passed |
19799a22 |
1063 | as part of C<@_> will be a reference to the actual argument given |
1064 | in the subroutine call, obtained by applying C<\> to that argument. |
c07a80fd |
1065 | |
5b794e05 |
1066 | You can also backslash several argument types simultaneously by using |
1067 | the C<\[]> notation: |
1068 | |
1069 | sub myref (\[$@%&*]) |
1070 | |
1071 | will allow calling myref() as |
1072 | |
1073 | myref $var |
1074 | myref @array |
1075 | myref %hash |
1076 | myref &sub |
1077 | myref *glob |
1078 | |
1079 | and the first argument of myref() will be a reference to |
1080 | a scalar, an array, a hash, a code, or a glob. |
1081 | |
c07a80fd |
1082 | Unbackslashed prototype characters have special meanings. Any |
19799a22 |
1083 | unbackslashed C<@> or C<%> eats all remaining arguments, and forces |
f86cebdf |
1084 | list context. An argument represented by C<$> forces scalar context. An |
1085 | C<&> requires an anonymous subroutine, which, if passed as the first |
0df79f0c |
1086 | argument, does not require the C<sub> keyword or a subsequent comma. |
1087 | |
1088 | A C<*> allows the subroutine to accept a bareword, constant, scalar expression, |
648ca4f7 |
1089 | typeglob, or a reference to a typeglob in that slot. The value will be |
1090 | available to the subroutine either as a simple scalar, or (in the latter |
0df79f0c |
1091 | two cases) as a reference to the typeglob. If you wish to always convert |
1092 | such arguments to a typeglob reference, use Symbol::qualify_to_ref() as |
1093 | follows: |
1094 | |
1095 | use Symbol 'qualify_to_ref'; |
1096 | |
1097 | sub foo (*) { |
1098 | my $fh = qualify_to_ref(shift, caller); |
1099 | ... |
1100 | } |
c07a80fd |
1101 | |
859a4967 |
1102 | A semicolon (C<;>) separates mandatory arguments from optional arguments. |
19799a22 |
1103 | It is redundant before C<@> or C<%>, which gobble up everything else. |
cb1a09d0 |
1104 | |
7adf2bcd |
1105 | As the last character of a prototype, or just before a semicolon, you can |
1106 | use C<_> in place of C<$>: if this argument is not provided, C<$_> will be |
1107 | used instead. |
859a4967 |
1108 | |
19799a22 |
1109 | Note how the last three examples in the table above are treated |
1110 | specially by the parser. C<mygrep()> is parsed as a true list |
1111 | operator, C<myrand()> is parsed as a true unary operator with unary |
1112 | precedence the same as C<rand()>, and C<mytime()> is truly without |
1113 | arguments, just like C<time()>. That is, if you say |
cb1a09d0 |
1114 | |
1115 | mytime +2; |
1116 | |
f86cebdf |
1117 | you'll get C<mytime() + 2>, not C<mytime(2)>, which is how it would be parsed |
19799a22 |
1118 | without a prototype. |
cb1a09d0 |
1119 | |
19799a22 |
1120 | The interesting thing about C<&> is that you can generate new syntax with it, |
1121 | provided it's in the initial position: |
d74e8afc |
1122 | X<&> |
cb1a09d0 |
1123 | |
6d28dffb |
1124 | sub try (&@) { |
cb1a09d0 |
1125 | my($try,$catch) = @_; |
1126 | eval { &$try }; |
1127 | if ($@) { |
1128 | local $_ = $@; |
1129 | &$catch; |
1130 | } |
1131 | } |
55497cff |
1132 | sub catch (&) { $_[0] } |
cb1a09d0 |
1133 | |
1134 | try { |
1135 | die "phooey"; |
1136 | } catch { |
1137 | /phooey/ and print "unphooey\n"; |
1138 | }; |
1139 | |
f86cebdf |
1140 | That prints C<"unphooey">. (Yes, there are still unresolved |
19799a22 |
1141 | issues having to do with visibility of C<@_>. I'm ignoring that |
f86cebdf |
1142 | question for the moment. (But note that if we make C<@_> lexically |
cb1a09d0 |
1143 | scoped, those anonymous subroutines can act like closures... (Gee, |
5f05dabc |
1144 | is this sounding a little Lispish? (Never mind.)))) |
cb1a09d0 |
1145 | |
19799a22 |
1146 | And here's a reimplementation of the Perl C<grep> operator: |
d74e8afc |
1147 | X<grep> |
cb1a09d0 |
1148 | |
1149 | sub mygrep (&@) { |
1150 | my $code = shift; |
1151 | my @result; |
1152 | foreach $_ (@_) { |
6e47f808 |
1153 | push(@result, $_) if &$code; |
cb1a09d0 |
1154 | } |
1155 | @result; |
1156 | } |
a0d0e21e |
1157 | |
cb1a09d0 |
1158 | Some folks would prefer full alphanumeric prototypes. Alphanumerics have |
1159 | been intentionally left out of prototypes for the express purpose of |
1160 | someday in the future adding named, formal parameters. The current |
1161 | mechanism's main goal is to let module writers provide better diagnostics |
1162 | for module users. Larry feels the notation quite understandable to Perl |
1163 | programmers, and that it will not intrude greatly upon the meat of the |
1164 | module, nor make it harder to read. The line noise is visually |
1165 | encapsulated into a small pill that's easy to swallow. |
1166 | |
420cdfc1 |
1167 | If you try to use an alphanumeric sequence in a prototype you will |
1168 | generate an optional warning - "Illegal character in prototype...". |
1169 | Unfortunately earlier versions of Perl allowed the prototype to be |
1170 | used as long as its prefix was a valid prototype. The warning may be |
1171 | upgraded to a fatal error in a future version of Perl once the |
1172 | majority of offending code is fixed. |
1173 | |
cb1a09d0 |
1174 | It's probably best to prototype new functions, not retrofit prototyping |
1175 | into older ones. That's because you must be especially careful about |
1176 | silent impositions of differing list versus scalar contexts. For example, |
1177 | if you decide that a function should take just one parameter, like this: |
1178 | |
1179 | sub func ($) { |
1180 | my $n = shift; |
1181 | print "you gave me $n\n"; |
54310121 |
1182 | } |
cb1a09d0 |
1183 | |
1184 | and someone has been calling it with an array or expression |
1185 | returning a list: |
1186 | |
1187 | func(@foo); |
1188 | func( split /:/ ); |
1189 | |
19799a22 |
1190 | Then you've just supplied an automatic C<scalar> in front of their |
f86cebdf |
1191 | argument, which can be more than a bit surprising. The old C<@foo> |
cb1a09d0 |
1192 | which used to hold one thing doesn't get passed in. Instead, |
19799a22 |
1193 | C<func()> now gets passed in a C<1>; that is, the number of elements |
1194 | in C<@foo>. And the C<split> gets called in scalar context so it |
1195 | starts scribbling on your C<@_> parameter list. Ouch! |
cb1a09d0 |
1196 | |
5f05dabc |
1197 | This is all very powerful, of course, and should be used only in moderation |
54310121 |
1198 | to make the world a better place. |
44a8e56a |
1199 | |
1200 | =head2 Constant Functions |
d74e8afc |
1201 | X<constant> |
44a8e56a |
1202 | |
1203 | Functions with a prototype of C<()> are potential candidates for |
19799a22 |
1204 | inlining. If the result after optimization and constant folding |
1205 | is either a constant or a lexically-scoped scalar which has no other |
54310121 |
1206 | references, then it will be used in place of function calls made |
19799a22 |
1207 | without C<&>. Calls made using C<&> are never inlined. (See |
1208 | F<constant.pm> for an easy way to declare most constants.) |
44a8e56a |
1209 | |
5a964f20 |
1210 | The following functions would all be inlined: |
44a8e56a |
1211 | |
699e6cd4 |
1212 | sub pi () { 3.14159 } # Not exact, but close. |
1213 | sub PI () { 4 * atan2 1, 1 } # As good as it gets, |
1214 | # and it's inlined, too! |
44a8e56a |
1215 | sub ST_DEV () { 0 } |
1216 | sub ST_INO () { 1 } |
1217 | |
1218 | sub FLAG_FOO () { 1 << 8 } |
1219 | sub FLAG_BAR () { 1 << 9 } |
1220 | sub FLAG_MASK () { FLAG_FOO | FLAG_BAR } |
54310121 |
1221 | |
1222 | sub OPT_BAZ () { not (0x1B58 & FLAG_MASK) } |
88267271 |
1223 | |
1224 | sub N () { int(OPT_BAZ) / 3 } |
1225 | |
1226 | sub FOO_SET () { 1 if FLAG_MASK & FLAG_FOO } |
1227 | |
1228 | Be aware that these will not be inlined; as they contain inner scopes, |
1229 | the constant folding doesn't reduce them to a single constant: |
1230 | |
1231 | sub foo_set () { if (FLAG_MASK & FLAG_FOO) { 1 } } |
1232 | |
1233 | sub baz_val () { |
44a8e56a |
1234 | if (OPT_BAZ) { |
1235 | return 23; |
1236 | } |
1237 | else { |
1238 | return 42; |
1239 | } |
1240 | } |
cb1a09d0 |
1241 | |
5a964f20 |
1242 | If you redefine a subroutine that was eligible for inlining, you'll get |
4cee8e80 |
1243 | a mandatory warning. (You can use this warning to tell whether or not a |
1244 | particular subroutine is considered constant.) The warning is |
1245 | considered severe enough not to be optional because previously compiled |
1246 | invocations of the function will still be using the old value of the |
19799a22 |
1247 | function. If you need to be able to redefine the subroutine, you need to |
4cee8e80 |
1248 | ensure that it isn't inlined, either by dropping the C<()> prototype |
19799a22 |
1249 | (which changes calling semantics, so beware) or by thwarting the |
4cee8e80 |
1250 | inlining mechanism in some other way, such as |
1251 | |
4cee8e80 |
1252 | sub not_inlined () { |
54310121 |
1253 | 23 if $]; |
4cee8e80 |
1254 | } |
1255 | |
19799a22 |
1256 | =head2 Overriding Built-in Functions |
d74e8afc |
1257 | X<built-in> X<override> X<CORE> X<CORE::GLOBAL> |
a0d0e21e |
1258 | |
19799a22 |
1259 | Many built-in functions may be overridden, though this should be tried |
5f05dabc |
1260 | only occasionally and for good reason. Typically this might be |
19799a22 |
1261 | done by a package attempting to emulate missing built-in functionality |
a0d0e21e |
1262 | on a non-Unix system. |
1263 | |
163e3a99 |
1264 | Overriding may be done only by importing the name from a module at |
1265 | compile time--ordinary predeclaration isn't good enough. However, the |
19799a22 |
1266 | C<use subs> pragma lets you, in effect, predeclare subs |
1267 | via the import syntax, and these names may then override built-in ones: |
a0d0e21e |
1268 | |
1269 | use subs 'chdir', 'chroot', 'chmod', 'chown'; |
1270 | chdir $somewhere; |
1271 | sub chdir { ... } |
1272 | |
19799a22 |
1273 | To unambiguously refer to the built-in form, precede the |
1274 | built-in name with the special package qualifier C<CORE::>. For example, |
1275 | saying C<CORE::open()> always refers to the built-in C<open()>, even |
fb73857a |
1276 | if the current package has imported some other subroutine called |
19799a22 |
1277 | C<&open()> from elsewhere. Even though it looks like a regular |
09bef843 |
1278 | function call, it isn't: you can't take a reference to it, such as |
19799a22 |
1279 | the incorrect C<\&CORE::open> might appear to produce. |
fb73857a |
1280 | |
19799a22 |
1281 | Library modules should not in general export built-in names like C<open> |
1282 | or C<chdir> as part of their default C<@EXPORT> list, because these may |
a0d0e21e |
1283 | sneak into someone else's namespace and change the semantics unexpectedly. |
19799a22 |
1284 | Instead, if the module adds that name to C<@EXPORT_OK>, then it's |
a0d0e21e |
1285 | possible for a user to import the name explicitly, but not implicitly. |
1286 | That is, they could say |
1287 | |
1288 | use Module 'open'; |
1289 | |
19799a22 |
1290 | and it would import the C<open> override. But if they said |
a0d0e21e |
1291 | |
1292 | use Module; |
1293 | |
19799a22 |
1294 | they would get the default imports without overrides. |
a0d0e21e |
1295 | |
19799a22 |
1296 | The foregoing mechanism for overriding built-in is restricted, quite |
95d94a4f |
1297 | deliberately, to the package that requests the import. There is a second |
19799a22 |
1298 | method that is sometimes applicable when you wish to override a built-in |
95d94a4f |
1299 | everywhere, without regard to namespace boundaries. This is achieved by |
1300 | importing a sub into the special namespace C<CORE::GLOBAL::>. Here is an |
1301 | example that quite brazenly replaces the C<glob> operator with something |
1302 | that understands regular expressions. |
1303 | |
1304 | package REGlob; |
1305 | require Exporter; |
1306 | @ISA = 'Exporter'; |
1307 | @EXPORT_OK = 'glob'; |
1308 | |
1309 | sub import { |
1310 | my $pkg = shift; |
1311 | return unless @_; |
1312 | my $sym = shift; |
1313 | my $where = ($sym =~ s/^GLOBAL_// ? 'CORE::GLOBAL' : caller(0)); |
1314 | $pkg->export($where, $sym, @_); |
1315 | } |
1316 | |
1317 | sub glob { |
1318 | my $pat = shift; |
1319 | my @got; |
19799a22 |
1320 | local *D; |
1321 | if (opendir D, '.') { |
1322 | @got = grep /$pat/, readdir D; |
1323 | closedir D; |
1324 | } |
1325 | return @got; |
95d94a4f |
1326 | } |
1327 | 1; |
1328 | |
1329 | And here's how it could be (ab)used: |
1330 | |
1331 | #use REGlob 'GLOBAL_glob'; # override glob() in ALL namespaces |
1332 | package Foo; |
1333 | use REGlob 'glob'; # override glob() in Foo:: only |
1334 | print for <^[a-z_]+\.pm\$>; # show all pragmatic modules |
1335 | |
19799a22 |
1336 | The initial comment shows a contrived, even dangerous example. |
95d94a4f |
1337 | By overriding C<glob> globally, you would be forcing the new (and |
19799a22 |
1338 | subversive) behavior for the C<glob> operator for I<every> namespace, |
95d94a4f |
1339 | without the complete cognizance or cooperation of the modules that own |
1340 | those namespaces. Naturally, this should be done with extreme caution--if |
1341 | it must be done at all. |
1342 | |
1343 | The C<REGlob> example above does not implement all the support needed to |
19799a22 |
1344 | cleanly override perl's C<glob> operator. The built-in C<glob> has |
95d94a4f |
1345 | different behaviors depending on whether it appears in a scalar or list |
19799a22 |
1346 | context, but our C<REGlob> doesn't. Indeed, many perl built-in have such |
95d94a4f |
1347 | context sensitive behaviors, and these must be adequately supported by |
1348 | a properly written override. For a fully functional example of overriding |
1349 | C<glob>, study the implementation of C<File::DosGlob> in the standard |
1350 | library. |
1351 | |
77bc9082 |
1352 | When you override a built-in, your replacement should be consistent (if |
1353 | possible) with the built-in native syntax. You can achieve this by using |
1354 | a suitable prototype. To get the prototype of an overridable built-in, |
1355 | use the C<prototype> function with an argument of C<"CORE::builtin_name"> |
1356 | (see L<perlfunc/prototype>). |
1357 | |
1358 | Note however that some built-ins can't have their syntax expressed by a |
1359 | prototype (such as C<system> or C<chomp>). If you override them you won't |
1360 | be able to fully mimic their original syntax. |
1361 | |
fe854a6f |
1362 | The built-ins C<do>, C<require> and C<glob> can also be overridden, but due |
77bc9082 |
1363 | to special magic, their original syntax is preserved, and you don't have |
1364 | to define a prototype for their replacements. (You can't override the |
1365 | C<do BLOCK> syntax, though). |
1366 | |
1367 | C<require> has special additional dark magic: if you invoke your |
1368 | C<require> replacement as C<require Foo::Bar>, it will actually receive |
1369 | the argument C<"Foo/Bar.pm"> in @_. See L<perlfunc/require>. |
1370 | |
1371 | And, as you'll have noticed from the previous example, if you override |
593b9c14 |
1372 | C<glob>, the C<< <*> >> glob operator is overridden as well. |
77bc9082 |
1373 | |
9b3023bc |
1374 | In a similar fashion, overriding the C<readline> function also overrides |
e3f73d4e |
1375 | the equivalent I/O operator C<< <FILEHANDLE> >>. Also, overriding |
1376 | C<readpipe> also overrides the operators C<``> and C<qx//>. |
9b3023bc |
1377 | |
fe854a6f |
1378 | Finally, some built-ins (e.g. C<exists> or C<grep>) can't be overridden. |
77bc9082 |
1379 | |
a0d0e21e |
1380 | =head2 Autoloading |
d74e8afc |
1381 | X<autoloading> X<AUTOLOAD> |
a0d0e21e |
1382 | |
19799a22 |
1383 | If you call a subroutine that is undefined, you would ordinarily |
1384 | get an immediate, fatal error complaining that the subroutine doesn't |
1385 | exist. (Likewise for subroutines being used as methods, when the |
1386 | method doesn't exist in any base class of the class's package.) |
1387 | However, if an C<AUTOLOAD> subroutine is defined in the package or |
1388 | packages used to locate the original subroutine, then that |
1389 | C<AUTOLOAD> subroutine is called with the arguments that would have |
1390 | been passed to the original subroutine. The fully qualified name |
1391 | of the original subroutine magically appears in the global $AUTOLOAD |
1392 | variable of the same package as the C<AUTOLOAD> routine. The name |
1393 | is not passed as an ordinary argument because, er, well, just |
593b9c14 |
1394 | because, that's why. (As an exception, a method call to a nonexistent |
1395 | C<import> or C<unimport> method is just skipped instead.) |
19799a22 |
1396 | |
1397 | Many C<AUTOLOAD> routines load in a definition for the requested |
1398 | subroutine using eval(), then execute that subroutine using a special |
1399 | form of goto() that erases the stack frame of the C<AUTOLOAD> routine |
1400 | without a trace. (See the source to the standard module documented |
1401 | in L<AutoLoader>, for example.) But an C<AUTOLOAD> routine can |
1402 | also just emulate the routine and never define it. For example, |
1403 | let's pretend that a function that wasn't defined should just invoke |
1404 | C<system> with those arguments. All you'd do is: |
cb1a09d0 |
1405 | |
1406 | sub AUTOLOAD { |
1407 | my $program = $AUTOLOAD; |
1408 | $program =~ s/.*:://; |
1409 | system($program, @_); |
54310121 |
1410 | } |
cb1a09d0 |
1411 | date(); |
6d28dffb |
1412 | who('am', 'i'); |
cb1a09d0 |
1413 | ls('-l'); |
1414 | |
19799a22 |
1415 | In fact, if you predeclare functions you want to call that way, you don't |
1416 | even need parentheses: |
cb1a09d0 |
1417 | |
1418 | use subs qw(date who ls); |
1419 | date; |
1420 | who "am", "i"; |
593b9c14 |
1421 | ls '-l'; |
cb1a09d0 |
1422 | |
1423 | A more complete example of this is the standard Shell module, which |
19799a22 |
1424 | can treat undefined subroutine calls as calls to external programs. |
a0d0e21e |
1425 | |
19799a22 |
1426 | Mechanisms are available to help modules writers split their modules |
1427 | into autoloadable files. See the standard AutoLoader module |
6d28dffb |
1428 | described in L<AutoLoader> and in L<AutoSplit>, the standard |
1429 | SelfLoader modules in L<SelfLoader>, and the document on adding C |
19799a22 |
1430 | functions to Perl code in L<perlxs>. |
cb1a09d0 |
1431 | |
09bef843 |
1432 | =head2 Subroutine Attributes |
d74e8afc |
1433 | X<attribute> X<subroutine, attribute> X<attrs> |
09bef843 |
1434 | |
1435 | A subroutine declaration or definition may have a list of attributes |
1436 | associated with it. If such an attribute list is present, it is |
0120eecf |
1437 | broken up at space or colon boundaries and treated as though a |
09bef843 |
1438 | C<use attributes> had been seen. See L<attributes> for details |
1439 | about what attributes are currently supported. |
1440 | Unlike the limitation with the obsolescent C<use attrs>, the |
1441 | C<sub : ATTRLIST> syntax works to associate the attributes with |
1442 | a pre-declaration, and not just with a subroutine definition. |
1443 | |
1444 | The attributes must be valid as simple identifier names (without any |
1445 | punctuation other than the '_' character). They may have a parameter |
1446 | list appended, which is only checked for whether its parentheses ('(',')') |
1447 | nest properly. |
1448 | |
1449 | Examples of valid syntax (even though the attributes are unknown): |
1450 | |
4358a253 |
1451 | sub fnord (&\%) : switch(10,foo(7,3)) : expensive; |
1452 | sub plugh () : Ugly('\(") :Bad; |
09bef843 |
1453 | sub xyzzy : _5x5 { ... } |
1454 | |
1455 | Examples of invalid syntax: |
1456 | |
4358a253 |
1457 | sub fnord : switch(10,foo(); # ()-string not balanced |
1458 | sub snoid : Ugly('('); # ()-string not balanced |
1459 | sub xyzzy : 5x5; # "5x5" not a valid identifier |
1460 | sub plugh : Y2::north; # "Y2::north" not a simple identifier |
1461 | sub snurt : foo + bar; # "+" not a colon or space |
09bef843 |
1462 | |
1463 | The attribute list is passed as a list of constant strings to the code |
1464 | which associates them with the subroutine. In particular, the second example |
1465 | of valid syntax above currently looks like this in terms of how it's |
1466 | parsed and invoked: |
1467 | |
1468 | use attributes __PACKAGE__, \&plugh, q[Ugly('\(")], 'Bad'; |
1469 | |
1470 | For further details on attribute lists and their manipulation, |
a0ae32d3 |
1471 | see L<attributes> and L<Attribute::Handlers>. |
09bef843 |
1472 | |
cb1a09d0 |
1473 | =head1 SEE ALSO |
a0d0e21e |
1474 | |
19799a22 |
1475 | See L<perlref/"Function Templates"> for more about references and closures. |
1476 | See L<perlxs> if you'd like to learn about calling C subroutines from Perl. |
a2293a43 |
1477 | See L<perlembed> if you'd like to learn about calling Perl subroutines from C. |
19799a22 |
1478 | See L<perlmod> to learn about bundling up your functions in separate files. |
1479 | See L<perlmodlib> to learn what library modules come standard on your system. |
1480 | See L<perltoot> to learn how to make object method calls. |