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.
  • by ziggy (25) on 2003.04.01 14:42 (#18625) Journal
    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 operations, conceptually is serialize_struct(@), while another is deserialize_struct($). (Or save/restore, or marshall/unmarshall, or read/write, or any other pair of similarly named operations.)

    If this operation is performed many times in a program, then it is worthwhile to place this operation in a single descriptively named sub. It's somewhat irrelevant that the operation is pack/unpack; it's a black box. If there's a bug, then you want to fix it once.

    On the other hand, I disagree that pack/unpack is a seldom used operation that should always be wrapped in a (descriptively named) sub. Down that path lies madness. The solution is to learn the language. If you cling to wrapping every piece of obscure syntax in a sub, then where does it all end? Do regexes and substitutions belong there? If you don't use splice very often, should it be wrapped as well?

    Sticking unexplained pack() calls right in the main code might be quick and easy, but think what you can gain with a well named subroutine with an obvious purpose that hides pack() away where you don't have to see it except when you want to.
    That's the Ostrich's solution. Don't hide from the language, learn how to use it.

    There are times where a single pack/unpack call is useful as a single standalone operation. If you think the usage is obscure, you could wrap it in a descriptively named sub. A better solution would be to comment the usage in place to make it less obscure.

    Think how you could write tests on just that subroutine. Think how the name makes the purpose clear. Think how the inexperienced programmer doesn't have to look up pack() if he knows he can trust that conversion routine. Think how you don't have to fool with it again if you know you can trust the routine.
    On the other hand, think about high level vs. low level operations. A perl programmer should never need to test to make sure that chomp($a = "foo\n") should yield $a eq "foo". There are times when a single high level operation will be concisely expressed in a pack, and should be wrapped in a sub. There are other times when pack is but one part of a single conceptual operation that should be tested as a whole -- otherwise, you're just writing tests to prove that 1+1 is still equal to 2. :-)
    • The solution is to learn the language.

      That idea alone could save buckets of time writing workarounds and useless comments.

      ... otherwise, you're just writing tests to prove that 1+1 is still equal to 2.

      Hey, I know a couple of people who've written tests just like that. Aren't you glad we aren't breaking chomp anymore?

      • That idea alone could save buckets of time writing workarounds and useless comments.

        A tradition at my old workplace persisted for years and passed on to every intern and co-op that when you wrote:

        open(FILE, $filename) || die "Cant open file: $!";

        you should leave out the apostrophe in the word "Can't," because that once broke something. Obviously, what it broke was somebody who tried to use single quotes for the whole thing, but that part wasn't understood.

        --
        J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
      • Hey, I know a couple of people who've written tests just like that. Aren't you glad we aren't breaking chomp anymore?

        Well, I added some tests to make sure that 1 + 1 == 2
        t/op/arith.t [activestate.com].

        Which reminds me - Schwern is not poorer yet :-( [mpe.mpg.de]

    • 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
      • 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

    • Don't hide from the language, learn how to use it.

      I've used Perl for over 5 years now, and consider myself to be reasonably profficient. Yet I'll admit to puzzling over the docs whenever I try to develop anything beyond trivial pack/unpack formats. The docs could use some good examples.