Slash Boxes
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.
More | Login | Reply
Loading... please wait.
  • So here's a thought: most uses of pack should be wrapped up in a small subroutine, shouldn't they? I mean, if you are unpacking a struct, make two routines (to convert either direction) that take binary data on one end and an array, hash, or object on the other.

    Whoa, boy. You've got a good idea, but you're starting to overgeneralize.

    What you're talking about is properly factoring your code. Your program is made up of a string of little operations performed in a meaningful order. One of those oper

    • You've got a good idea, but you're starting to overgeneralize.

      Story of my life, I'll admit. :)

      On the other hand, I disagree that pack/unpack is a seldom used operation that should always be wrapped in a (descriptively named) sub.

      Oh, I don't believe it's a seldom used operation. It's seldom used by me, but I know it's in wide use across the world. And I fully agree with you that the solution is to learn the language. I'm not trying to argue that everyone should put pack in a sub to make me happ

      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
      • by ziggy (25) on 2003.04.01 15:41 (#18632) Journal
        A lot of the Oracle books I'm reading push me in the direction of making clearly named subprograms in lieu of comments. Since lost of developers don't like comments, it seems like it's worth considering, although I agree with you that something that is obscure (not something that's just an idiom I don't know, but something that is truly obscure) should be commented to explain it. Whether wrapped in a sub or not, actually.
        Yes, this is the general idea behind factoring. The best texts I can recommend are Leo Brodie's FORTH books, "Starting FORTH" and "Thinking FORTH". FORTH is a language that demands proper factoring; without it, it would be impossible to get anything written or maintain a program for periods longer than a workweek. They're both out of print, so good luck finding them.

        The key to factoring is learning when to factor. If you can turn a single pack into one logical and reusable operation, then it belongs in a sub. If it is just a piece of obscure syntax, throw some commentary around it.