Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • The issue I run into day-to-day is building in hooks for future needs. You don't want to build code that can't be easily modified, but nor do you need a plug-in framework based on future conjecture.
    --

    --
    xoa

    • There's also an open source myth in there somewhere. (I should be writing that article, not eating a candy bar and reading use Perl;.)

      There was a discussion on Perl Monks today about access checking. The poster just needed to check if a given user name is in the list of admins. That's pretty simple: just a hash look up.

      While I normally use exists to avoid autovivification issues, one poster claimed that that was bad design. "What if you add administrative levels in the future and one of those levels

      • The problem with Perl for this sort of thing is you run smack bang into the issue of the amount of cruft you need to write to get your encapsulated method up and running.

        sub is_an_admin {
                my($self, $user) = @_;
                exists $self->{admins}{$user}; # Or whatever
        }

        When you're encapsulating a one line test that's an awful lot of stuff, but if you want maintainability you just have to bite the bullet (and the performance hit). Roll on Perl 6.

        method is_an_admin { exists %.admins{$^user} }

        However, I would like to add a loud "Hear! Hear!" to your main point.