use Perl

• The future (Score:3, Insightful)

  by petdance (2468)

  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
  • Re:The future (Score:1)

    by chromatic (983)

    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
    • Re:The future (Score:1)

      by pdcawley (485) on 2003.10.31 3:32 (#25337) Homepage Journal

      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.

      Reply to This

      Parent