in reply to Factoring out common code in two methods of a class

That is a very cumbersome way to do things, as well as being a performance penalty rebuilding the template every time you use it.

The basic problem is that you are setting up a (series of) variable(s), when you should be using a constant!

Yes, the template might need to change in the future, but it won't be changing at runtime, so it is a constant. Both sets of lines can be replaced by a single line (and a comment): 

use constant PACK_TEMPLATE = 'H4 b7 b1 b1 b1 b6 H2 A8 H4';
=comment 
'H4';# 16 bits     Msg ID                          
'b7';# 7 bits      Frag Seq                        
'b'; # 1 bit       More Frags flag                 
'b'; # 1 bit       Unit ID Present                 
'b'; # 1 bit       CRC Present                     
'b6'; # 6 bits Unused
'H2'; # 8 bits     Frag Length  
'A8'; # if present, unit ID is 8 chars
'H4'; # if present, CRC is a 16 bit word                      
=cut

[download]

Now, you just use PACK_TEMPLATE (give it a better name appropriate to your application), whereever you need it. It will be private to the package/class you declare it in, so there are no action at distance concerns.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
RIP PCW

Replies are listed 'Best First'.
Re^2: Factoring out common code in two methods of a class
by jvector (Friar) on Aug 05, 2009 at 18:48 UTC

    Thanks for that. I had wondered about "use constant..." but had it in my head that I would need a constant for each 'field' and been put off by the anticipated verbosity of it. But I had been blinkered about putting them all into one constant.

    I guess I'll have to leave off the last two parts which in this application are optional, and add them to PACK_TEMPLATE programatically after the length field ... hmm, that's OK.

    And yes, you're right that there is a performance implication on constructing that format string each time. Not a lot, but every little bit hurts...

    The next signature will be better than this one
[reply]
[d/l]
      I guess I'll have to leave off the last two parts which in this application are optional, and add them to PACK_TEMPLATE programatically after the length field

      Personally, I'd just create 2 or 3 constants and select between them at runtime: 

      use constant T1 = '...';
use constant T2 = t1 . '...';
use constant T3 = T1 . '...';
# or 
use constant T3 = T2 . '...';

...

my $packed = pack ( T1, T2, T3 )[ condition() ], @bits;

      [download]

      Wher condition() returns an integer 0 .. 2.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]
      I guess I'll have to leave off the last two parts which in this application are optional, and add them to PACK_TEMPLATE programatically after the length field ... hmm, that's OK.
      No, create a function with the 2 optional parts as input and the string $pack_template as output.
[reply]
        No, create a function with the 2 optional parts as input and the string $pack_template as output.

        What!? What possible merit is there is creating a function to do concatenation? Perl has an operator to do that: 

         my $packed = pack PACK_TEMPLATE . (condition ? OPTIONAL_ADDITION : ''
+), @bits;

        [download]
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
      I had wondered about "use constant..." but had it in my head that I would need a constant for each 'field'

      I often do things like this - that is, reject a solution prematurely based on perceived drawbacks. Usually I haven't thought about the problem in enough depth. I find it's very helpful to sit down and actually WRITE DOWN the requirements (or constraints) for a particular problem, then think through them in detail. (For me, the physical act of writing, be it with keyboard or pen, helps me engage in the thinking-through process.)

[reply]

In Section Seekers of Perl Wisdom