summaryrefslogtreecommitdiff
path: root/pod/perlsub.pod
diff options
context:
space:
mode:
Diffstat (limited to 'pod/perlsub.pod')
-rw-r--r--pod/perlsub.pod4
1 files changed, 2 insertions, 2 deletions
diff --git a/pod/perlsub.pod b/pod/perlsub.pod
index 927e944c93..46d1a2a2b0 100644
--- a/pod/perlsub.pod
+++ b/pod/perlsub.pod
@@ -179,7 +179,7 @@ when just naming the subroutine, such as when it's used as
an argument to defined() or undef(). Nor is it optional when you
want to do an indirect subroutine call with a subroutine name or
reference using the C<&$subref()> or C<&{$subref}()> constructs,
-although the C<$subref-E<gt>()> notation solves that problem.
+although the C<< $subref->() >> notation solves that problem.
See L<perlref> for more about all that.
Subroutines may be called recursively. If a subroutine is called
@@ -891,7 +891,7 @@ like a built-in function. If you call it like an old-fashioned
subroutine, then it behaves like an old-fashioned subroutine. It
naturally falls out from this rule that prototypes have no influence
on subroutine references like C<\&foo> or on indirect subroutine
-calls like C<&{$subref}> or C<$subref-E<gt>()>.
+calls like C<&{$subref}> or C<< $subref->() >>.
Method calls are not influenced by prototypes either, because the
function to be called is indeterminate at compile time, since