Source

perl-begin / lib / tutorials / modern-perl / xhtml / chapter_11.html

  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
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta name="generator" content="HTML Tidy for Linux (vers 25 March 2009), see www.w3.org" />
<title></title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<link rel="stylesheet" href="../styles/style.css" type="text/css" />
</head>
<body>
<h1 id="heading_id_2">What to Avoid</h1>
<p>Perl 5 isn't perfect. Some features are difficult to use correctly. Otherwise have never worked well. A few are quirky combinations of other features with strange edge cases. While you're better off avoiding these features, knowing why to avoid them will help you find better solutions.</p>
<h2 id="heading_id_3">Barewords</h2>
<div id="barewords"></div>
<p>Perl is a malleable language. You can write programs in the most creative, maintainable, obfuscated, or bizarre fashion you prefer. Maintainability is a concern of good programmers, but Perl doesn't presume to dictate what <em>you</em> consider maintainable.</p>
<div id="ibarewords_0"></div>
<div id="istrict_pragma_1"></div>
<div id="ipragmas__istrict_2"></div>
<p>Perl's parser understands Perl's builtins and operators. It uses sigils to identify variables and other punctuation to recognize function and method calls. Yet sometimes the parser has to guess what you mean, especially when you use a <em>bareword</em>--an identifier without a sigil or other syntactically significant punctuation.</p>
<h3 id="heading_id_4">Good Uses of Barewords</h3>
<div id="ibarewords__ipros_0"></div>
<p>Though the <code>strict</code> pragma (<a href="chapter_08.html#pragmas">Pragmas</a>(pragmas)) rightly forbids ambiguous barewords, some barewords are acceptable.</p>
<h4 id="heading_id_5">Bareword hash keys</h4>
<div id="ihashes__ibareword_keys_0"></div>
<div id="i43__iunary_operator_0"></div>
<p>Hash keys in Perl 5 are usually <em>not</em> ambiguous because the parser can identify them as string keys; <code>pinball</code> in <code>$games{pinball}</code> is obviously a string.</p>
<p>Occasionally this interpretation is not what you want, especially when you intend to <em>evaluate</em> a builtin or a function to produce the hash key. In this case, disambiguate by providing arguments, using function argument parentheses, or prepending unary plus to force the evaluation of the builtin:</p>
<div class="programlisting">
<pre>
<code>    # the literal 'shift' is the key
    my $value = $items{<strong>shift</strong>};

    # the value produced by shift is the key
    my $value = $items{<strong>shift @_</strong>}

    # unary plus uses the builtin shift
    my $value = $items{<strong>+</strong>shift};</code>
</pre></div>
<h4 id="heading_id_6">Bareword package names</h4>
<div id="ipackages__ibareword_names_0"></div>
<p>Package names in Perl 5 are also barewords. If you hew to naming conventions where package names have initial capitals and functions do not, you'll rarely encounter naming collisions, but the Perl 5 parser must determine how to parse <code>Package-&gt;method()</code>. Does it mean "call a function named <code>Package()</code> and call <code>method()</code> on its return value?" or does it mean "Call a method named <code>method()</code> in the <code>Package</code> namespace?" The answer varies depending on what code the parser has already encountered in the current namespace.</p>
<p>Force the parser to treat <code>Package</code> as a package name by appending the package separator (<code>::</code>) <span class="footnote">(footnote: Even among people who understand why this works, very few people do it.)</span>:</p>
<div class="programlisting">
<pre>
<code>    # probably a class method
    Package-&gt;method();

    # definitely a class method
    Package::-&gt;method();</code>
</pre></div>
<h4 id="heading_id_7">Bareword named code blocks</h4>
<div id="iBEGIN_1"></div>
<div id="iDESTROY_0"></div>
<div id="iAUTOLOAD_1"></div>
<div id="iINIT_0"></div>
<div id="iUNITCHECK_0"></div>
<div id="iCHECK_0"></div>
<div id="iEND_0"></div>
<p>The special named code blocks <code>AUTOLOAD</code>, <code>BEGIN</code>, <code>CHECK</code>, <code>DESTROY</code>, <code>END</code>, <code>INIT</code>, and <code>UNITCHECK</code> are barewords which <em>declare</em> functions without the <code>sub</code> builtin. You've seen this before (<a href="chapter_09.html#code_generation">Code Generation</a>(code_generation)):</p>
<div class="programlisting">
<pre>
<code>    package Monkey::Butler;

    BEGIN { initialize_simians( __PACKAGE__ ) }

    sub AUTOLOAD { ... }</code>
</pre></div>
<p>While you <em>can</em> elide <code>sub</code> from <code>AUTOLOAD()</code> declarations, few people do.</p>
<h4 id="heading_id_8">Bareword constants</h4>
<div id="iconstants__ibarewords_0"></div>
<p>Constants declared with the <code>constant</code> pragma are usable as barewords:</p>
<div class="programlisting">
<pre>
<code>    # don't use this for real authentication
    use constant NAME     =&gt; 'Bucky';
    use constant PASSWORD =&gt; '|38fish!head74|';

    return unless $name eq NAME &amp;&amp; $pass eq PASSWORD;</code>
</pre></div>
<p>Note that these constants do <em>not</em> interpolate in double-quoted strings.</p>
<div id="iprototypes__ibarewords_0"></div>
<p>Constants are a special case of prototyped functions (<a href="chapter_11.html#prototypes">Prototypes</a>(prototypes)). When you predeclare a function with a prototype, the parser knows how to treat that function and will warn about ambiguous parsing errors. All other drawbacks of prototypes still apply.</p>
<h3 id="heading_id_9">Ill-Advised Uses of Barewords</h3>
<div id="ibarewords__icons_0"></div>
<p>No matter how cautiously you code, barewords still produce ambiguous code. You can avoid most uses, but you will encounter several types of barewords in legacy code.</p>
<h4 id="heading_id_10">Bareword function calls</h4>
<div id="ibarewords__ifunction_calls_0"></div>
<div id="iB5858Deparse_1"></div>
<p>Code written without <code>strict 'subs'</code> may use bareword function names. Adding parentheses makes the code pass strictures. Use <code>perl -MO=Deparse,-p</code> (see <code>perldoc B::Deparse</code>) to discover how Perl parses them, then parenthesize accordingly.</p>
<h4 id="heading_id_11">Bareword hash values</h4>
<div id="ibarewords__ihash_values_0"></div>
<p>Some old code may not take pains to quote the <em>values</em> of hash pairs:</p>
<div class="programlisting">
<pre>
<code>    # poor style; do not use
    my %parents =
    (
        mother =&gt; Annette,
        father =&gt; Floyd,
    );</code>
</pre></div>
<p>When neither the <code>Floyd()</code> nor <code>Annette()</code> functions exist, Perl will interpret these barewords as strings. <code>strict 'subs'</code> will produce an error in this situation.</p>
<h4 id="heading_id_12">Bareword filehandles</h4>
<div id="ibarewords__ifilehandles_0"></div>
<p>Prior to lexical filehandles (<a href="chapter_03.html#lexical_filehandles">Filehandle References</a>(lexical_filehandles)), all file and directory handles used barewords. You can almost always safely rewrite this code to use lexical filehandles; the exceptions are <code>STDIN</code>, <code>STDOUT</code>, and <code>STDERR</code>. Fortunately, Perl's parser recognizes these.</p>
<h4 id="heading_id_13">Bareword sort functions</h4>
<div id="ibarewords__isort_functions_0"></div>
<div id="isort_0"></div>
<div id="ibuiltins__isort_2"></div>
<p>Finally, the <code>sort</code> builtin can take as its second argument the <em>name</em> of a function to use for sorting. While this is rarely ambiguous to the parser, it can confuse <em>human</em> readers. The alternative of providing a function reference in a scalar is little better:</p>
<div class="programlisting">
<pre>
<code>    # bareword style
    my @sorted = sort compare_lengths @unsorted;

    # function reference in scalar
    my $comparison = \&amp;compare_lengths;
    my @sorted     = sort $comparison @unsorted;</code>
</pre></div>
<p>The second option avoids the use of a bareword, but the result is one line longer. Unfortunately, Perl 5's parser <em>does not</em> understand the single-line version due to the special parsing of <code>sort</code>; you cannot use an arbitrary expression (such as taking a reference to a named function) where a block or a scalar might otherwise go.</p>
<div class="programlisting">
<pre>
<code>    # does not work
    my @sorted = sort \&amp;compare_lengths @unsorted;</code>
</pre></div>
<p>In both cases, the way <code>sort</code> invokes the function and provides arguments can be confusing (see <code>perldoc -f sort</code> for the details). Where possible, consider using the block form of <code>sort</code> instead. If you must use either function form, consider adding an explanatory comment.</p>
<h2 id="heading_id_14">Indirect Objects</h2>
<div id="indirect_objects"></div>
<p>Perl 5 has no operator <code>new</code>; a constructor in Perl 5 is anything which returns an object. By convention, constructors are class methods named <code>new()</code>, but you can choose anything you like. Several old Perl 5 object tutorials promote the use of C++ and Java-style constructor calls:</p>
<div class="programlisting">
<pre>
<code>    my $q = <strong>new</strong> CGI; # DO NOT USE</code>
</pre></div>
<p>... instead of the obvious method call:</p>
<div class="programlisting">
<pre>
<code>    my $q = CGI-&gt;new();</code>
</pre></div>
<p>These syntaxes produce equivalent behavior, except when they don't.</p>
<h3 id="heading_id_15">Bareword Indirect Invocations</h3>
<div id="iindirect_object_notation_0"></div>
<div id="idative_notation_0"></div>
<p>In the indirect object form (more precisely, the <em>dative</em> case) of the first example, the verb (the method) precedes the noun to which it refers (the object). This is fine in spoken languages, but it introduces parsing ambiguities in Perl 5.</p>
<p>As the method name is a bareword (<a href="chapter_11.html#barewords">Barewords</a>(barewords)), the parser must divine the proper interpretation of the code through the use of several heuristics. While these heuristics are well-tested and <em>almost</em> always correct, their failure modes are confusing. Worse yet, they depend on the order of compilation of code and modules.</p>
<p>Parsing difficulty increases when the constructor takes arguments. The indirect style may resemble:</p>
<div class="programlisting">
<pre>
<code>    # DO NOT USE
    my $obj = new Class( arg =&gt; $value );</code>
</pre></div>
<p>... thus making the name of the class look like a function call. Perl 5 <em>can</em> disambiguate many of these cases, but its heuristics depend on which package names the parser has seen, which barewords it has already resolved (and how it resolved them), and the <em>names</em> of functions already declared in the current package.</p>
<p>Imagine running afoul of a prototyped function (<a href="chapter_11.html#prototypes">Prototypes</a>(prototypes)) with a name which just happens to conflict somehow with the name of a class or a method called indirectly. This is rare, but so unpleasant to debug that it's worth avoiding indirect invocations.</p>
<h3 id="heading_id_16">Indirect Notation Scalar Limitations</h3>
<p>Another danger of the syntax is that the parser expects a single scalar expression as the object. Printing to a filehandle stored in an aggregate variable <em>seems</em> obvious, but it is not:</p>
<div class="programlisting">
<pre>
<code>    # DOES NOT WORK AS WRITTEN
    say $config-&gt;{output} 'Fun diagnostic message!';</code>
</pre></div>
<p>Perl will attempt to call <code>say</code> on the <code>$config</code> object.</p>
<div id="ibuiltins__iprint_2"></div>
<div id="ibuiltins__iclose_1"></div>
<div id="ibuiltins__isay_2"></div>
<p><code>print</code>, <code>close</code>, and <code>say</code>--all builtins which operate on filehandles--operate in an indirect fashion. This was fine when filehandles were package globals, but lexical filehandles (<a href="chapter_03.html#lexical_filehandles">Filehandle References</a>(lexical_filehandles)) make the indirect object syntax problems obvious. To solve this, disambiguate the subexpression which produces the intended invocant:</p>
<div class="programlisting">
<pre>
<code>    say <strong>{</strong>$config-&gt;{output}<strong>}</strong> 'Fun diagnostic message!';</code>
</pre></div>
<h3 id="heading_id_17">Alternatives to Indirect Notation</h3>
<p>Direct invocation notation does not suffer this ambiguity problem. To construct an object, call the constructor method on the class name directly:</p>
<div class="programlisting">
<pre>
<code>    my $q   = CGI-&gt;new();
    my $obj = Class-&gt;new( arg =&gt; $value );</code>
</pre></div>
<p>This syntax <em>still</em> has a bareword problem in that if you have a function named <code>CGI</code>, Perl will interpret the bareword class name as a call to the function, as:</p>
<div class="programlisting">
<pre>
<code>    sub CGI;

    # you wrote CGI-&gt;new(), but Perl saw
    my $q = CGI()-&gt;new();</code>
</pre></div>
<p>While this happens rarely, you can disambiguate classnames by appending the package separator (<code>::</code>) or by explicitly marking class names as string literals:</p>
<div class="programlisting">
<pre>
<code>    # package separator
    my $q = CGI::-&gt;new();

    # unambiguously a string literal
    my $q = 'CGI'-&gt;new();</code>
</pre></div>
<p>Yet almost no one ever does this.</p>
<div id="iIO5858File_2"></div>
<p>For the limited case of filehandle operations, the dative use is so prevalent that you can use the indirect invocation approach if you surround your intended invocant with curly brackets. If you're using Perl 5.14 (or if you load <code>IO::File</code> or <code>IO::Handle</code>), you can use methods on lexical filehandles <span class="footnote">(footnote: Almost no one does this for <code>print</code> and <code>say</code> though.)</span>.</p>
<div id="iCPAN__iPerl5858Critic_2"></div>
<div id="iCPAN__iPerl5858Critic5858Policy5858Dynamic5858NoIndirect_0"></div>
<div id="iCPAN__iindirect_1"></div>
<p>The CPAN module <code>Perl::Critic::Policy::Dynamic::NoIndirect</code> (a plugin for <code>Perl::Critic</code>) can identify indirect invocations during code reviews. The CPAN module <code>indirect</code> can identify and prohibit their use in running programs:</p>
<div class="programlisting">
<pre>
<code>    # warn on indirect use
    no indirect;

    # throw exceptions on their use
    no indirect ':fatal';</code>
</pre></div>
<h2 id="heading_id_18">Prototypes</h2>
<div id="prototypes"></div>
<div id="iprototypes_0"></div>
<p>A <em>prototype</em> is a piece of optional metadata attached to a function which changes the way the parser understands its arguments. While they may superficially resemble function signatures in other languages, they are very different.</p>
<div id="ibuiltins__ipush_3"></div>
<p>Prototypes allow users to define their own functions which behave like builtins. Consider the builtin <code>push</code>, which takes an array and a list. While Perl 5 would normally flatten the array and list into a single list passed to <code>push</code>, the parser knows not to flatten the array so that <code>push</code> can modify it in place.</p>
<p>Function prototypes are part of declarations:</p>
<div class="programlisting">
<pre>
<code>    sub foo        <strong>(&amp;@)</strong>;
    sub bar        <strong>($$)</strong> { ... }
    my  $baz = sub <strong>(&amp;&amp;)</strong> { ... };</code>
</pre></div>
<p>Any prototype attached to a forward declaration must match the prototype attached to the function declaration. Perl will give a warning if this is not true. Strangely you may omit the prototype from a forward declaration and include it for the full declaration--but there's no reason to do so.</p>
<div id="ibuiltins__iprototype_0"></div>
<p>The builtin <code>prototype</code> takes the name of a function and returns a string representing its prototype. Use the <code>CORE::</code> form to see the prototype of a builtin:</p>
<div class="screen">
<pre>
<code>    $ <strong>perl -E "say prototype 'CORE::push';"</strong>
    \@@
    $ <strong>perl -E "say prototype 'CORE::keys';"</strong>
    \%
    $ <strong>perl -E "say prototype 'CORE::open';"</strong>
    *;$@</code>
</pre></div>
<p><code>prototype</code> will return <code>undef</code> for those builtins whose functions you cannot emulate:</p>
<div class="screen">
<pre>
<code>    <strong>say prototype 'CORE::system' // 'undef'</strong>
    # undef; cannot emulate builtin <code>system</code>

    <strong>say prototype 'CORE::prototype' // 'undef'</strong>
    # undef; builtin <code>prototype</code> has no prototype</code>
</pre></div>
<p>Remember <code>push</code>?</p>
<div class="screen">
<pre>
<code>    $ <strong>perl -E "say prototype 'CORE::push';"</strong>
    \@@</code>
</pre></div>
<p>The <code>@</code> character represents a list. The backslash forces the use of a <em>reference</em> to the corresponding argument. This prototype means that <code>push</code> takes a reference to an array and a list of values. You might write <code>mypush</code> as:</p>
<div class="programlisting">
<pre>
<code>    sub mypush (\@@)
    {
        my ($array, @rest) = @_;
        push @$array, @rest;
    }</code>
</pre></div>
<p>Other prototype characters include <code>$</code> to force a scalar argument, <code>%</code> to mark a hash (most often used as a reference), and <code>&amp;</code> to identify a code block. See <code>perldoc perlsub</code> for full documentation.</p>
<h3 id="heading_id_19">The Problem with Prototypes</h3>
<p>Prototypes change how Perl parses your code and can cause argument type coercions. They do not document the number or types of arguments functions expect, nor do they map arguments to named parameters.</p>
<p>Prototype coercions work in subtle ways, such as enforcing scalar context on incoming arguments:</p>
<div class="programlisting">
<pre>
<code>    sub numeric_equality($$)
    {
        my ($left, $right) = @_;
        return $left == $right;
    }

    my @nums = 1 .. 10;

    say 'They're equal, whatever that means!'
        if numeric_equality @nums, 10;</code>
</pre></div>
<p>... but only work on simple expressions:</p>
<div class="programlisting">
<pre>
<code>    sub mypush(\@@);

    # compilation error: prototype mismatch
    # (expected array, got scalar assignment)
    mypush( my $elems = [], 1 .. 20 );</code>
</pre></div>
<p>To debug this, users of <code>mypush</code> must know both that a prototype exists, and the limitations of the array prototype. Worse yet, these are the <em>simple</em> errors prototypes can cause.</p>
<h3 id="heading_id_20">Good Uses of Prototypes</h3>
<div id="ibuiltins__ioverriding_0"></div>
<div id="ipragmas__isubs_1"></div>
<div id="isubs_pragma_1"></div>
<p>Few uses of prototypes are compelling enough to overcome their drawbacks, but they exist.</p>
<p>First, they can allow you to override builtins. First check that you <em>can</em> override the builtin by examining its prototype in a small test program. Then use the <code>subs</code> pragma to tell Perl that you plan to override a builtin, and finally declare your override with the correct prototype:</p>
<div class="programlisting">
<pre>
<code>    use subs 'push';

    sub push (\@@) { ... }</code>
</pre></div>
<p>Beware that the <code>subs</code> pragma is in effect for the remainder of the <em>file</em>, regardless of any lexical scoping.</p>
<div id="iconstants_0"></div>
<p>The second reason to use prototypes is to define compile-time constants. When Perl encounters a function declared with an empty prototype (as opposed to <em>no</em> prototype) <em>and</em> this function evaluates to a single constant expression, the optimizer will turn all calls to that function into constants instead of function calls:</p>
<div class="programlisting">
<pre>
<code>    sub PI () { 4 * atan2(1, 1) }</code>
</pre></div>
<p>All subsequent code will use the calculated value of pi in place of the bareword <code>PI</code> or a call to <code>PI()</code>, with respect to scoping and visibility.</p>
<div id="iconstant_pragma_0"></div>
<div id="ipragmas__iconstant_1"></div>
<div id="iCPAN__iConst5858Fast_0"></div>
<p>The core pragma <code>constant</code> handles these details for you. The <code>Const::Fast</code> module from the CPAN creates constant scalars which you can interpolate into strings.</p>
<div id="iCPAN__iTest5858Exception_1"></div>
<div id="iCPAN__iTest5858Fatal_2"></div>
<p>A reasonable use of prototypes is to extend Perl's syntax to operate on anonymous functions as blocks. The CPAN module <code>Test::Exception</code> uses this to good effect to provide a nice API with delayed computation <span class="footnote">(footnote: See also <code>Test::Fatal</code>)</span>. Its <code>throws_ok()</code> function takes three arguments: a block of code to run, a regular expression to match against the string of the exception, and an optional description of the test:</p>
<div class="programlisting">
<pre>
<code>    use Test::More tests =&gt; 1;
    use Test::Exception;

    throws_ok
        { my $unobject; $unobject-&gt;yoink() }
        qr/Can't call method "yoink" on an undefined/,
        'Method on undefined invocant should fail';</code>
</pre></div>
<p>The exported <code>throws_ok()</code> function has a prototype of <code>&amp;$;$</code>. Its first argument is a block, which becomes an anonymous function. The second argument is a scalar. The third argument is optional.</p>
<p>Careful readers may have spotted the absence of a comma after the block. This is a quirk of the Perl 5 parser, which expects whitespace after a prototyped block, not the comma operator. This is a drawback of the prototype syntax.</p>
<p>You may use <code>throws_ok()</code> without taking advantage of the prototype:</p>
<div class="programlisting">
<pre>
<code>    use Test::More tests =&gt; 1;
    use Test::Exception;

    throws_ok<strong>(</strong>
        <strong>sub</strong> { my $unobject; $unobject-&gt;yoink() }<strong>,</strong>
        qr/Can't call method "yoink" on an undefined/,
        'Method on undefined invocant should fail' <strong>)</strong>;</code>
</pre></div>
<div id="ibuiltins__isort_3"></div>
<p>A final good use of prototypes is when defining a custom named function to use with <code>sort</code> <span class="footnote">(footnote: Ben Tilly suggested this example.)</span>:</p>
<div class="programlisting">
<pre>
<code>    sub length_sort ($$)
    {
        my ($left, $right) = @_;
        return length($left) &lt;=&gt; length($right);
    }

    my @sorted = sort length_sort @unsorted;</code>
</pre></div>
<p>The prototype of <code>$$</code> forces Perl to pass the sort pairs in <code>@_</code>. <code>sort</code>'s documentation suggests that this is slightly slower than using the package globals <code>$a</code> and <code>$b</code>, but using lexical variables often makes up for any speed penalty.</p>
<h2 id="heading_id_21">Method-Function Equivalence</h2>
<div id="method_sub_equivalence"></div>
<div id="ibuiltins__isub_3"></div>
<p>Perl 5's object system is deliberately minimal (<a href="chapter_07.html#blessed_references">Blessed References</a>(blessed_references)). Because a class is a package, Perl does not distinguish between a function and a method stored in a package. The same builtin, <code>sub</code>, declares both. Documentation can clarify your intent, but Perl will happily dispatch to a function called as a method. Likewise, you can invoke a method as if it were a function--fully-qualified, exported, or as a reference--if you pass in your own invocant manually.</p>
<p>Invoking the wrong thing in the wrong way causes problems.</p>
<h3 id="heading_id_22">Caller-side</h3>
<p>Consider a class with several methods:</p>
<div class="programlisting">
<pre>
<code>    package Order;

    use List::Util 'sum';

    ...

    sub calculate_price
    {
        my $self = shift;
        return sum( 0, $self-&gt;get_items() );
    }</code>
</pre></div>
<p>Given an <code>Order</code> object <code>$o</code>, the following invocations of this method <em>may</em> seem equivalent:</p>
<div class="programlisting">
<pre>
<code>    my $price = $o-&gt;calculate_price();

    # broken; do not use
    my $price = Order::calculate_price( $o );</code>
</pre></div>
<p>Though in this simple case, they produce the same output, the latter violates object encapsulation by avoiding method lookup.</p>
<div id="imethods__iavoid_calling_as_functions_0"></div>
<p>If <code>$o</code> were instead a subclass or allomorph (<a href="chapter_07.html#roles">Roles</a>(roles)) of <code>Order</code> which overrode <code>calculate_price()</code>, bypassing method dispatch would call the wrong method. Any change to the implementation of <code>calculate_price()</code>, such as a modification of inheritance or delegation through <code>AUTOLOAD()</code>--might break calling code.</p>
<div id="imethods__icalling_with_references_0"></div>
<div id="iUNIVERSAL__ican4041_0"></div>
<div id="ican4041_2"></div>
<p>Perl has one circumstance where this behavior may seem necessary. If you force method resolution without dispatch, how do you invoke the resulting method reference?</p>
<div class="programlisting">
<pre>
<code>    my $meth_ref = $o-&gt;can( 'apply_discount' );</code>
</pre></div>
<p>There are two possibilities. The first is to discard the return value of the <code>can()</code> method:</p>
<div class="programlisting">
<pre>
<code>    $o-&gt;apply_discount() if $o-&gt;can( 'apply_discount' );</code>
</pre></div>
<p>The second is to use the reference itself with method invocation syntax:</p>
<div class="programlisting">
<pre>
<code>    if (my $meth_ref = $o-&gt;can( 'apply_discount' ))
    {
        $o-&gt;$meth_ref();
    }</code>
</pre></div>
<p>When <code>$meth_ref</code> contains a function reference, Perl will invoke that reference with <code>$o</code> as the invocant. This works even under strictures, as it does when invoking a method with a scalar containing its name:</p>
<div class="programlisting">
<pre>
<code>    my $name = 'apply_discount';
    $o-&gt;$name();</code>
</pre></div>
<p>There is one small drawback in invoking a method by reference; if the structure of the program changes between storing the reference and invoking the reference, the reference may no longer refer to the most appropriate method. If the <code>Order</code> class has changed such that <code>Order::apply_discount</code> is no longer the right method to call, the reference in <code>$meth_ref</code> will not have updated.</p>
<p>When you use this invocation form, limit the scope of the references.</p>
<h3 id="heading_id_23">Callee-side</h3>
<div id="imethods__iavoid_calling_as_functions_1"></div>
<div id="ifunctions__iavoid_calling_as_methods_0"></div>
<p>Because Perl 5 makes no distinction between functions and methods at the point of declaration and because it's <em>possible</em> (however inadvisable) to invoke a given function as a function or a method, it's possible to write a function callable as either. The core <code>CGI</code> module is a prime offender. Its functions apply several heuristics to determine whether their first arguments are invocants.</p>
<p>The drawbacks are many. It's difficult to predict exactly which invocants are potentially valid for a given method, especially when you may have to deal with subclasses. Creating an API that users cannot easily misuse is more difficult too, as is your documentation burden. What happens when one part of the project uses the procedural interface and another uses the object interface?</p>
<p>If you <em>must</em> provide a separate procedural and OO interface to a library, create two separate APIs.</p>
<h2 id="heading_id_24">Tie</h2>
<div id="tie"></div>
<p>Where overloading (<a href="chapter_09.html#overloading">Overloading</a>(overloading)) allows you to customize the behavior of classes and objects for specific types of coercion, a mechanism called <em>tying</em> allows you to customize the behavior of primitive variables (scalars, arrays, hashes, and filehandles). Any operation you might perform on a tied variable translates to a specific method call.</p>
<div id="ibuiltins__itie_0"></div>
<div id="iTie5858File_0"></div>
<p>The <code>tie</code> builtin originally allowed you to use disk space as the backing memory for hashes, so that Perl could access files larger than could easily fit in memory. The core module <code>Tie::File</code> provides a similar system, and allows you to treat files as if they were arrays.</p>
<div id="iTie5858StdScalar_0"></div>
<div id="iTie5858StdArray_0"></div>
<div id="iTie5858StdHash_0"></div>
<p>The class to which you <code>tie</code> a variable must conform to a defined interface for a specific data type. See <code>perldoc perltie</code> for an overview, then consult the core modules <code>Tie::StdScalar</code>, <code>Tie::StdArray</code>, and <code>Tie::StdHash</code> for specific details. Start by inheriting from one of those classes, then override any specific methods you need to modify.</p>
<div class="tip">
<p>If <code>tie</code> weren't confusing enough, <code>Tie::Scalar</code>, <code>Tie::Array</code>, and <code>Tie::Hash</code> define the necessary interfaces to tie scalars, arrays, and hashes, but <code>Tie::StdScalar</code>, <code>Tie::StdArray</code>, and <code>Tie::StdHash</code> provide the default implementations.</p>
</div>
<h3 id="heading_id_25">Tying Variables</h3>
<p>To tie a variable:</p>
<div class="programlisting">
<pre>
<code>    use Tie::File;
    tie my @file, 'Tie::File', @args;</code>
</pre></div>
<p>The first argument is the variable to tie, the second is the name of the class into which to tie it, and <code>@args</code> is an optional list of arguments required for the tying function. In the case of <code>Tie::File</code>, this is a valid filename.</p>
<div id="ibuiltins__itie_1"></div>
<div id="ibuiltins__itied_0"></div>
<p>Tying functions resemble constructors: <code>TIESCALAR</code>, <code>TIEARRAY()</code>, <code>TIEHASH()</code>, or <code>TIEHANDLE()</code> for scalars, arrays, hashes, and filehandles respectively. Each function returns a new object which represents the tied variable. Both the <code>tie</code> and <code>tied</code> builtins return this object. Most people use <code>tied</code> in a boolean context, however.</p>
<h3 id="heading_id_26">Implementing Tied Variables</h3>
<p>To implement the class of a tied variable, inherit from a core module such as <code>Tie::StdScalar</code> <span class="footnote">(footnote: <code>Tie::StdScalar</code> lacks its own <em>.pm</em> file, so use <code>Tie::Scalar</code> to make it available.)</span>, then override the specific methods for the operations you want to change. In the case of a tied scalar, these are likely <code>FETCH</code> and <code>STORE</code>, possibly <code>TIESCALAR()</code>, and probably not <code>DESTROY()</code>.</p>
<p>You can create a class which logs all reads from and writes to a scalar with very little code:</p>
<div class="programlisting">
<pre>
<code>    package Tie::Scalar::Logged
    {
        use Modern::Perl;

        use Tie::Scalar;
        use parent -norequire =&gt; 'Tie::StdScalar';

        sub STORE
        {
            my ($self, $value) = @_;
            Logger-&gt;log("Storing &lt;$value&gt; (was [$$self])", 1);
            $$self = $value;
        }

        sub FETCH
        {
            my $self = shift;
            Logger-&gt;log("Retrieving &lt;$$self&gt;", 1);
            return $$self;
        }
    }

    1;</code>
</pre></div>
<p>Assume that the <code>Logger</code> class method <code>log()</code> takes a string and the number of frames up the call stack of which to report the location.</p>
<p>Within the <code>STORE()</code> and <code>FETCH()</code> methods, <code>$self</code> works as a blessed scalar. Assigning to that scalar reference changes the value of the scalar and reading from it returns its value.</p>
<p>Similarly, the methods of <code>Tie::StdArray</code> and <code>Tie::StdHash</code> act on blessed array and hash references, respectively. The <code>perldoc perltie</code> documentation explains the copious methods they support, as you can read or write multiple values from them, among other operations.</p>
<div class="tip">
<p>The <code>-norequire</code> option prevents the <code>parent</code> pragma from attempting to load a file for <code>Tie::StdScalar</code>, as that module is part of the file <em>Tie/Scalar.pm</em>.</p>
</div>
<h3 id="heading_id_27">When to use Tied Variables</h3>
<p>Tied variables seem like fun opportunities for cleverness, but they can produce confusing interfaces. Unless you have a very good reason for making objects behave as if they were builtin data types, avoid creating your own ties. <code>tie</code> is also much slower than using the builtin types due to various reasons of implementation.</p>
<p>Good reasons include to ease debugging (use the logged scalar to help you understand where a value changes) and to make certain impossible operations possible (accessing large files in a memory-efficient way). Tied variables are less useful as the primary interfaces to objects; it's often too difficult and constraining to try to fit your whole interface to that supported by <code>tie()</code>.</p>
<p>The final word of warning is both sad and convincing; too much code goes out of its way to <em>prevent</em> use of tied variables, often by accident. This is unfortunate, but violating the expectations of library code tends to reveal bugs that are often out of your power to fix.</p>
</body>
</html>