http://www.perlmonks.org?node_id=517963


in reply to RFC: Perl Second-Best Practices

Oh, wow, where to start? There are a lot of nasty things I do in Perl that are actually necessary. Sometimes, they're necessary simply because the code is (originally) intended to be a quick one-off for debugging or proof-of-concept purposes, so spending 3 hours doing it "right" loses out to spending 10 minutes to get it done. And sometimes, they're necessary because there simply isn't a nicer way of doing it.

Here's a sample "second-best" pattern that I've used recently, that causes co-workers and bosses to cringe, despite being reasonably sane and acceptable. I've seen it pop up all over, most recently in merlyn's SysAdmin article:

... { no strict 'refs'; *{"${class}::get_${name}"} = sub { ... }; } ...
The "no strict 'refs'" and symbol-table mucking is certainly justified, because there's really no better way to do it, but it still feels "second-best" to me.

Replies are listed 'Best First'.
Re^2: RFC: Perl Second-Best Practices
by chromatic (Archbishop) on Dec 24, 2005 at 20:14 UTC

    sfink is right. Also, japhy noticed recently that disabling strict references at the top of the scope there disables them inside the anonymous subroutine. It's better to declare the subroutine and then disable strict references and assign to the typeglob:

    { my $sub = sub { ... }; no strict 'refs'; *{ "${class}::get_${name}" } = $sub; }
      *{; do { no strict 'refs'; \*{ "${class}::get_${name}" } } } = sub { . +.. };

      Makeshifts last the longest.

Re^2: RFC: Perl Second-Best Practices
by sfink (Deacon) on Dec 24, 2005 at 20:01 UTC
    I'm not very good at symbol table stuff, but it seems like you could spell that out with less punctuation and in a strict-safe way with
    $main::{$class."::"}{"get_$name"} = sub { ... }

      Not if $class contains "::" (at least not on the last version of Perl I tried it on).

      [ Though, I suppose you could throw Data::Diver into the mix to solve that problem and get a much more complicated solution that meets some irrational fear of ever disabling 'strict' :) ]

      - tye