Alt-Lexical-Var-ButSupportModernPerl

 view release on metacpan or  search on metacpan

lib/Lexical/Sub.pm  view on Meta::CPAN

This module influences the meaning of single-part subroutine names that
appear directly in code, such as "C<&foo>" and "C<foo(123)>".
Normally, in the absence of
any particular declaration, these would refer to the subroutine of that
name located in the current package.  A C<Lexical::Sub> declaration
can change this to refer to any particular subroutine, bypassing the
package system entirely.  A subroutine name that includes an explicit
package part, such as "C<&main::foo>", always refers to the subroutine
in the specified package, and is unaffected by this module.  A symbolic
reference through a string value, such as "C<&{'foo'}>", also looks in
the package system, and so is unaffected by this module.

Bareword references to subroutines, such as "C<foo(123)>", only work on
Perl 5.11.2 and later.  On earlier Perls you must use the C<&> sigil,
as in "C<&foo(123)>".

A name definition supplied by this module takes effect from the end of the
definition statement up to the end of the immediately enclosing block,
except where it is shadowed within a nested block.  This is the same
lexical scoping that the C<my>, C<our>, and C<state> keywords supply.

lib/Lexical/Sub.pm  view on Meta::CPAN

will be dissociated if and only if it is currently associated with
that subroutine.

=back

=head1 BUGS

Subroutine invocations without the C<&> sigil cannot be correctly
processed on Perl versions earlier than 5.11.2.  This is because
the parser needs to look up the subroutine early, in order to let any
prototype affect parsing, and it looks up the subroutine by a different
mechanism than is used to generate the call op.  (Some forms of sigilless
call have other complications of a similar nature.)  If an attempt
is made to call a lexical subroutine via a bareword on an older Perl,
this module will probably still be able to intercept the call op, and
will throw an exception to indicate that the parsing has gone wrong.
However, in some cases compilation goes further wrong before this
module can catch it, resulting in either a confusing parse error or
(in rare situations) silent compilation to an incorrect op sequence.
On Perl 5.11.2 and later, sigilless subroutine calls work correctly,
except for an issue noted below.

lib/Lexical/Var.pm  view on Meta::CPAN

This module influences the meaning of single-part variable names that
appear directly in code, such as "C<$foo>".  Normally, in the absence
of any particular declaration, or under the effect of an C<our>
declaration, this would refer to the scalar variable of that name
located in the current package.  A C<Lexical::Var> declaration can
change this to refer to any particular scalar, bypassing the package
system entirely.  A variable name that includes an explicit package part,
such as "C<$main::foo>", always refers to the variable in the specified
package, and is unaffected by this module.  A symbolic reference through
a string value, such as "C<${'foo'}>", also looks in the package system,
and so is unaffected by this module.

The types of name that can be influenced are scalar ("C<$foo>"),
array ("C<@foo>"), hash ("C<%foo>"), subroutine ("C<&foo>"), and glob
("C<*foo>").  A definition for any of these names also affects code
that logically refers to the same entity, even when the name is spelled
without its usual sigil.  For example, any definition of "C<@foo>" affects
element references such as "C<$foo[0]>".  Barewords in filehandle context
actually refer to the glob variable.  Bareword references to subroutines,
such as "C<foo(123)>", only work on Perl 5.11.2 and later; on earlier

lib/Lexical/Var.pm  view on Meta::CPAN

the name will be dissociated if and only if it is currently associated
with that value.

=back

=head1 BUGS

Subroutine invocations without the C<&> sigil cannot be correctly
processed on Perl versions earlier than 5.11.2.  This is because
the parser needs to look up the subroutine early, in order to let any
prototype affect parsing, and it looks up the subroutine by a different
mechanism than is used to generate the call op.  (Some forms of sigilless
call have other complications of a similar nature.)  If an attempt
is made to call a lexical subroutine via a bareword on an older Perl,
this module will probably still be able to intercept the call op, and
will throw an exception to indicate that the parsing has gone wrong.
However, in some cases compilation goes further wrong before this
module can catch it, resulting in either a confusing parse error or
(in rare situations) silent compilation to an incorrect op sequence.
On Perl 5.11.2 and later, sigilless subroutine calls work correctly,
except for an issue noted below.