in reply to strict and symbolic subroutine refs

I have three opinions on the matter.

1. use strict should prevent people from doing that since it's no different than variables. It could be a bug. But it's documented. This is to make goto &$AUTOLOAD not break.

2. Are you sure that the solution to your problem, which dances around what is "allowed" and what isn't in terms of strictness is correct in the maintainable sense?

3. If you're undermining use strict, but know how what you're doing is "bad" and furthermore, know what you're doing, what does it really matter? You could keep a hash of subreferences, and in practice you'll be doing the same thing (the symbol table is a hash), except in a syntatically more recognizable way. use strict is meant to be a tool that helps you not shoot yourself in the foot. If you find it limiting, or find yourself needing to see where it is limiting to get some work done, I don't think it's being used correctly.

-nuffin
zz zZ Z Z #!perl

Replies are listed 'Best First'.
Re^2: strict and symbolic subroutine refs
by tinita (Parson) on Jul 24, 2004 at 14:42 UTC
    You could keep a hash of subreferences, and in practice you'll be doing the same thing (the symbol table is a hash),
    we're not talking about me having a problem with strict.pm. (1) =)
    actually i never used the my $coderef = main->can($subname) thing for projects i'm programming on. just for trying out.
    i'm well aware that a hash of subrefs would be the way to go, i just saw that code \&$subname somewhere, and i really never stumbled upon that paragraph in strict.pm where it is documented.
    it's just that i usually thought that would require no strict, and i find that in more people's code that they are doing something like that:
    no strict;
my $ref = \&$name;

    [download]
    so i was really surprised it worked with strict.

    (1) i'm using 'no strict' a lot, though, for munging the symbol table (dynmic class generation and things like that)

[reply]
[d/l]
[select]
      I sounded a bit pedantic, I regret to admit.

      What I really meant was that even if no strict is unnecessary, it might be a good idea to put it there so the code is more self documenting, or to use a solution that doesn't need no strict (is that a double negative?), not because it is a better solution, but because it might be more coherent. The code refs in hash was just an example, I guess.

      -nuffin
      zz zZ Z Z #!perl
[reply]
[d/l]
[select]
        I sounded a bit pedantic, I regret to admit.
        no no, i think it's absolutely right to suggest an alternative like coderefs in a hash whenever such a question arises. those who don't know what kind of problems &{'subname'} can bring with it will appreciate it.

        i still wish i head read the docs more carefully before asking and then reading it ten minutes after, but, interesting, after asking around it turns out that i'm not the only one who missed that strict-exception. =)

[reply]
[d/l]

In Section Seekers of Perl Wisdom