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

use Perl Log In

Log In

[ Create a new account ]

jdavidb (1361)

jdavidb
  (email not shown publicly)
http://voiceofjohn.blogspot.com/
J. David Blackstone has a Bachelor of Science in Computer Science and Engineering and nine years of experience at a wireless telecommunications company, where he learned Perl and never looked back. J. David has an advantage in that he works really hard, he has a passion for writing good software, and he knows many of the world's best Perl programmers.

Journal of jdavidb (1361)

Tuesday April 01, 2003
12:31 PM

Wrapping pack()

[ #11377 ]

In all of my days, I can only remember using pack() once in a production application. That's not because it's not useful; it's because I'm fortunate to deal almost exclusively in text in my work. I know I've used it in some tinier things but none come to mind.

Having little pack() experience, I find pack templates to be as incomprehensible as regexes to a VB programmer. Without online reference material I'd never have a chance.

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. If you're performing some other conversion, say, converting epoch seconds to Julian dates with a brilliant use of pack that shaves .001 microseconds off of each iteration, make a subroutine called epoch2julian() that contains your pack call.

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

Oh, I see to be gushing. I'm suddenly reminded of perlstyle:

Think about reusability. Why waste brainpower on a one-shot when you might want to do something like it again? Consider generalizing your code. Consider writing a module or object class. Consider making your code run cleanly with use strict and use warnings (or -w) in effect. Consider giving away your code. Consider changing your whole world view. Consider... oh, never mind.


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Wrapping pack() 13 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
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

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

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

    Eh... I have to confess, I've written pretty much such a module... I haven't released it to the public, and likely I never will, because, well, you can read the responses from other people here.

    I wrote it, when trying to convert the utility progr

    • Eh... I have to confess, I've written pretty much such a module... I haven't released it to the public, and likely I never will, because, well, you can read the responses from other people here.

      Why not????? Don't let the opinions of people sway your view of how useful the module is, nor let you pass up a chance to submit it to others to see how useful they think it is. We operate on the economy of ideas. Just because your idea doesn't work for some people doesn't mean everyone will dislike it. That'

      --
      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
    • I think it sounds like a good idea. It also sounds a lot like the newly released Win32::API where I think you can do something similar when calling funcions with C structs.
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.