9.1 Tying Scalars

At the most basic level, there are only four things you can do with a scalar. You can create it, get or set its value, and destroy it (by ending the scope or undef 'ing it). tie allows you to supply a subroutine to be called back for each of these operations.

The syntax of tie is as follows:

tie 

variable

, 

classname

, 

list

;

The first parameter should be one of the four supported types described above. The second parameter is the name of a user-defined class. You are expected to have invoked use classname or require classname before calling tie .

When this statement is executed, Perl checks the type of the variable (the first parameter). It then calls the method classname ->TIESCALAR( list ) , or TIEARRAY , TIEHASH , or TIEHANDLE , depending on whether the tied variable is a scalar, array, hash, or filehandle. It is a run-time error if this method is not present in the class. TIESCALAR() is expected to return an object, which is then internally associated with (or tied to) the given variable. Now, when you read and write to the variable, Perl internally calls object ->FETCH() and object ->STORE( new value ) , respectively. Finally, when the tied variable goes out of scope, Perl calls object ->DESTROY() . Simple, isn't it?

The names FETCH , STORE , and TIESCALAR are similar to AUTOLOAD and DESTROY in that they have a special significance for Perl only under appropriate circumstances. That is, a module can have a method called FETCH , which can be used normally like any other user-defined subroutine. But if you use tie , this method assumes a special meaning.

Perl does not care about the exact data structure used for the object (whether you used a hash or ObjectTemplate). Table 9.1 shows a variable " $temperature " tied to an automatic temperature control system, which is represented by a Perl module called AC.pm.[ 1 ] An attempt to read $temperature 's value is translated to a call to the temperature sensor, and an attempt to set its value translates to a command to the heating system to do what is needed.

[1] Air conditioning, not alternating current!

tie $temperature,     'AC';

$obj = AC->TIESCALAR()

package AC; sub TIESCALAR {   ...   $ac = bless {...},         $pkg;   return $ac; }

$x = $temperature;

$x = $obj->FETCH();

sub FETCH {   $ac->get_temp(); }

$temperature = 20;

$obj->STORE(20);

sub STORE {  ($obj, $t) = @_;  $ac->set_temp($t); }

untie $temperature; #or undef $temperature;

$obj->DESTROY()

sub DESTROY { }

As you can see, the AC module is an ordinary class with a constructor and three object methods (whose names happen to be special). Perl interacts with this module behind the scenes, providing the user with a much simpler interaction model. You can get the tied object as the return value of tie or invoke the tied function to get to it at any other time. Therefore the statement

$temperature = 20;

is identical to

(tied $temperature)->STORE(20);

The untie function restores the original value of the variable and also calls the object's DESTROY method.

Perl does not constrain the object's module in any way other than to expect it to provide the methods we saw earlier. It can store whatever data it wants, can have other methods, and is perfectly usable even in a non-tie context.

use Stopwatch; tie $s, 'Stopwatch';  # $s is scalar transparently tied to a Stopwatch object. $s = 0;             # Writing to it forces a reset sleep(10);          # Sleep 10 seconds print "$s\n";       # Should print 10

package Stopwatch;  sub TIESCALAR {    my ($pkg) = @_;    my $obj = time();  # $obj stores the time at last reset.    return (bless \$obj, $pkg); }  sub FETCH {    my ($r_obj) = @_;    # Return the time elapsed since it was last reset     return (time() - $$r_obj);  }  sub STORE {    my ($r_obj, $val) = @_;    # Ignore the value. Any write to it is seen as a reset    return ($$r_obj = time()); }  1;

$r = \$s;  tie $$r, 'Stopwatch';  # Indirect tie to $s  @foo = (1, 2); tie $foo[1], 'Stopwatch';