Re: Calling locally manufactured (typeglob) methods

0..9 aren't valid identifiers, so you can't use them as glob names just like that (and you really shouldn't).

A trick is to make $method contain the package name explicitly:

package GlobTest;

BEGIN{
    for my $method ( map { __PACKAGE__ . '::' . $_ } 0..9 ) {
        no strict 'refs';
        *$method = sub { return $_ };
    }
}

sub new { bless {}, shift }
[download]

That makes all tests pass. But again, I don't think numerical method names are a good idea.

Comment on Re: Calling locally manufactured (typeglob) methods Download Code

Replies are listed 'Best First'.
Re^2: Calling locally manufactured (typeglob) methods by ysth (Canon) on Apr 05, 2007 at 16:37 UTC
0..9 aren't valid identifiers, so you can't use them as glob names just like that (and you really shouldn't). They are valid identifiers (e.g. `$^O = ~ /(.*)/; print "os: $1\n";`), just special ones. As perlvar says: Perl identifiers that begin with digits, control characters, or punctuation characters are exempt from the effects of the package declaration and are always forced to be in package main	[reply] [d/l]
Re^3: Calling locally manufactured (typeglob) methods by rhesa (Vicar) on Apr 05, 2007 at 18:34 UTC
Sure, sure. They're valid enough in that respect. But it also says: Perl variable names may also be a sequence of digits or a single punctuation or control character. These names are all reserved for special uses by Perl; That means you're not supposed to use them outside their intended, reserved, special contexts. What's more: `% perl -e 'my $14' Can't use global $14 in "my" at -e line 1, at end of line % perl -e '$1 = q/foo/' Modification of a read-only value attempted at -e line 1. % perl -e 'sub 14 { 14 }' Illegal declaration of anonymous subroutine at -e line 1.` [download] Doesn't look very valid on the face of it, does it? So in order to (ab)use them like ordinary identifiers at all, you have to jump through hoops. And you'll get pummeled to death by your coworkers or future maintenance programmers. That's why I said "invalid". It may not be technically precise, but in practice it's accurate enough.	[reply] [d/l]