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.
  • 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 happy; I'm trying to say that while thinking of pack I came up with this idea that might help some people and wanted to float it around. [Hmm, you just reminded me of the boss who decreed we could never use if at the end of a statement because it confused him. He got agreement from everyone on the team but me, because they were all new but me.]

      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?

      A very good point.

      A better solution would be to comment the usage in place to make it less obscure.

      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.

      There are other times when pack is but one part of a single conceptual operation that should be tested as a whole

      That was actually kind of at the back of my mind, but I didn't mention it. I was thinking more of subroutines that "pack and do a couple of other things," although I was encouraging the thought of going ahead and sticking all packs in a subroutine call.

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

      We will never have to worry about that until Perl 6, because backward compatibility is always guaranteed! ;)

      Thanks for being a useful counterpoint to my thinking.

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