=item 5.
X<constructor> X<new>
-References are often returned by special subroutines called constructors.
-Perl objects are just references to a special type of object that happens to know
-which package it's associated with. Constructors are just special
-subroutines that know how to create that association. They do so by
-starting with an ordinary reference, and it remains an ordinary reference
-even while it's also being an object. Constructors are often
-named new() and called indirectly:
+References are often returned by special subroutines called constructors. Perl
+objects are just references to a special type of object that happens to know
+which package it's associated with. Constructors are just special subroutines
+that know how to create that association. They do so by starting with an
+ordinary reference, and it remains an ordinary reference even while it's also
+being an object. Constructors are often named C<new()>. You I<can> call them
+indirectly:
- $objref = new Doggie (Tail => 'short', Ears => 'long');
+ $objref = new Doggie( Tail => 'short', Ears => 'long' );
-But don't have to be:
+But that can produce ambiguous syntax in certain cases, so it's often
+better to use the direct method invocation approach:
$objref = Doggie->new(Tail => 'short', Ears => 'long');
print $$$$refrefref;
=item 2.
-X<${}> X<@{}> X<%{}>
Anywhere you'd put an identifier (or chain of identifiers) as part of a
variable or subroutine name, you can replace the identifier with a
it's presumably referencing. That would be case 3.
=item 3.
-X<autovivification> X<< -> >> X<arrow>
Subroutine calls and lookups of individual array elements arise often
enough that it gets cumbersome to use method 2. As a form of
to grow its arrays on demand. Perl does.
=item 4.
-X<encapsulation>
If a reference happens to be a reference to an object, then there are
probably methods to access the things referred to, and you should probably
print "That yields @{[$n + 5]} widgets\n";
+Similarly, an expression that returns a reference to a scalar can be
+dereferenced via C<${...}>. Thus, the above expression may be written
+as:
+
+ print "That yields ${\($n + 5)} widgets\n";
+
=head2 Symbolic references
X<reference, symbolic> X<reference, soft>
X<symbolic reference> X<soft reference>
putting the whole loop of assignments within a BEGIN block, forcing it
to occur during compilation.
-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. 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:
+Access to lexicals that change over time--like those in the C<for> loop
+above, basically aliases to elements from the surrounding lexical scopes--
+only works with anonymous subs, not with named subroutines. Generally
+said, named subroutines do not nest properly and should only be declared
+in the main package scope.
+
+This is because named subroutines are created at compile time so their
+lexical variables get assigned to the parent lexicals from the first
+execution of the parent block. If a parent scope is entered a second
+time, its lexicals are created again, while the nested subs still
+reference the old ones.
+
+Anonymous subroutines get to capture each time you execute the C<sub>
+operator, as they are created on the fly. 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" due to the reasons explained above.
+For example, this won't work:
sub outer {
my $x = $_[0] + 35;
}
Now inner() can only be called from within outer(), because of the
-temporary assignments of the closure (anonymous subroutine). But when
-it does, it has normal access to the lexical variable $x from the scope
-of outer().
+temporary assignments of the anonymous subroutine. But when it does,
+it has normal access to the lexical variable $x from the scope of
+outer() at the time outer is invoked.
This has the interesting effect of creating a function local to another
function, something not normally supported in Perl.
https://perl5.git.perl.org / perl5.git / blobdiff