Symbolic references are names of variables or other objects, just as a
symbolic link in a Unix filesystem contains merely the name of a file.
-The C<*glob> notation is something of a of symbolic reference. (Symbolic
+The C<*glob> notation is something of a symbolic reference. (Symbolic
references are sometimes called "soft references", but please don't call
them that; references are confusing enough without useless synonyms.)
the IO handle, used for file handles (L<perlfunc/open>), sockets
(L<perlfunc/socket> and L<perlfunc/socketpair>), and directory
handles (L<perlfunc/opendir>). For compatibility with previous
-versions of Perl, C<*foo{FILEHANDLE}> is a synonym for C<*foo{IO}>.
+versions of Perl, C<*foo{FILEHANDLE}> is a synonym for C<*foo{IO}>, though it
+is deprecated as of 5.8.0. If deprecation warnings are in effect, it will warn
+of its use.
C<*foo{THING}> returns undef if that particular THING hasn't been used yet,
except in the case of scalars. C<*foo{SCALAR}> returns a reference to an
=head2 Pseudo-hashes: Using an array as a hash
-B<WARNING>: This section describes an experimental feature. Details may
-change without notice in future versions.
-
-Beginning with release 5.005 of Perl, you may use an array reference
-in some contexts that would normally require a hash reference. This
-allows you to access array elements using symbolic names, as if they
-were fields in a structure.
-
-For this to work, the array must contain extra information. The first
-element of the array has to be a hash reference that maps field names
-to array indices. Here is an example:
-
- $struct = [{foo => 1, bar => 2}, "FOO", "BAR"];
-
- $struct->{foo}; # same as $struct->[1], i.e. "FOO"
- $struct->{bar}; # same as $struct->[2], i.e. "BAR"
-
- keys %$struct; # will return ("foo", "bar") in some order
- values %$struct; # will return ("FOO", "BAR") in same some order
-
- while (my($k,$v) = each %$struct) {
- print "$k => $v\n";
- }
-
-Perl will raise an exception if you try to access nonexistent fields.
-To avoid inconsistencies, always use the fields::phash() function
-provided by the C<fields> pragma.
-
- use fields;
- $pseudohash = fields::phash(foo => "FOO", bar => "BAR");
-
-For better performance, Perl can also do the translation from field
-names to array indices at compile time for typed object references.
-See L<fields>.
-
-There are two ways to check for the existence of a key in a
-pseudo-hash. The first is to use exists(). This checks to see if the
-given field has ever been set. It acts this way to match the behavior
-of a regular hash. For instance:
-
- use fields;
- $phash = fields::phash([qw(foo bar pants)], ['FOO']);
- $phash->{pants} = undef;
-
- print exists $phash->{foo}; # true, 'foo' was set in the declaration
- print exists $phash->{bar}; # false, 'bar' has not been used.
- print exists $phash->{pants}; # true, your 'pants' have been touched
-
-The second is to use exists() on the hash reference sitting in the
-first array element. This checks to see if the given key is a valid
-field in the pseudo-hash.
-
- print exists $phash->[0]{bar}; # true, 'bar' is a valid field
- print exists $phash->[0]{shoes};# false, 'shoes' can't be used
-
-delete() on a pseudo-hash element only deletes the value corresponding
-to the key, not the key itself. To delete the key, you'll have to
-explicitly delete it from the first hash element.
-
- print delete $phash->{foo}; # prints $phash->[1], "FOO"
- print exists $phash->{foo}; # false
- print exists $phash->[0]{foo}; # true, key still exists
- print delete $phash->[0]{foo}; # now key is gone
- print $phash->{foo}; # runtime exception
+Pseudo-hashes have been removed from Perl. The 'fields' pragma
+remains available.
=head2 Function Templates
-As explained above, a closure is an anonymous function with access to the
-lexical variables visible when that function was compiled. It retains
-access to those variables even though it doesn't get run until later,
-such as in a signal handler or a Tk callback.
+As explained above, an anonymous function with access to the lexical
+variables visible when that function was compiled, creates a closure. It
+retains access to those variables even though it doesn't get run until
+later, such as in a signal handler or a Tk callback.
Using a closure as a function template allows us to generate many functions
that act similarly. Suppose you wanted functions named after the colors
Access to lexicals that change over type--like those in the C<for> loop
above--only works with closures, not general subroutines. In the general
case, then, named subroutines do not nest properly, although anonymous
-ones do. If you are accustomed to using nested subroutines in other
-programming languages with their own private variables, you'll have to
-work at it a bit in Perl. The intuitive coding of this type of thing
-incurs mysterious warnings about ``will not stay shared''. For example,
-this won't work:
+ones do. Thus is because named subroutines are created (and capture any
+outer lexicals) only once at compile time, whereas anonymous subroutines
+get to capture each time you execute the 'sub' operator. If you are
+accustomed to using nested subroutines in other programming languages with
+their own private variables, you'll have to work at it a bit in Perl. The
+intuitive coding of this type of thing incurs mysterious warnings about
+``will not stay shared''. For example, this won't work:
sub outer {
my $x = $_[0] + 35;