in reply to my $var = ''; vs. use constant VAR => '';

'use constant' doesn't appear to be terribly popualar, as 'my' does effectively the same thing, without the child-proof safety locks that prevent you from modifying variables declared that way.

Instead of declaring a whole whack of constants using my(), such as: 
    my ($filename) = "/path/to/file";
    my ($filemode) = "immolate";
    my ($opmode)   = "seek";
    my ($filetype) = "image/gif";

[download]
You could always convert this to a hash-structure, such as: 
    my (%config) = (
           filename => "/path/to/file",
           filemode => "immolate",
           opmode   => "seek",
           filetype => "image/gif",
    );

[download]
This has the advantage of allowing you to declare virtually unlimited constants, without having to explicitly declare them on their own my() line. Additionally, you can load these from a file quickly and easily (i.e. an INI-type file, an Apache-style file, or something else) such that you can vary the configuration without modifying the program itself.

Of course, using a hash-lookup is slower than a regular variable, but the price you pay would depend on frequency of use, and in practice, should be so slight as to really be irrelevant. In most cases where a constant is used frequently, such as inside a loop, you would expect to see something like: 
     my ($thing) = $config{'thing_to_mash'};
     for (my $x = 0; $x < 100_000_000; $x++)
     {
           DoCrazyStuff($thing, $x, Foo($x));
     }

[download]
In this admittedly simple example, the hash is only used once, and the variable itself is repeatedly used.

If you really don't trust yourself to keep your const's constant, and to not modify them in any way, write a function to extract parameters from it, such as:     sub Config { return $config{$_[0]}; } Then you could keep %config in some sort of codeblock or module which nobody has access too. This is kind of extreme, though.

Replies are listed 'Best First'.
scalar my vs list my
by merlyn (Sage) on Apr 27, 2001 at 01:11 UTC 
        my ($filename) = "/path/to/file"; 
    my ($filemode) = "immolate"; 
    my ($opmode)   = "seek"; 
    my ($filetype) = "image/gif";

    [download]
    As a matter of style (and occasionally necessity), I leave off the parens on those leftsides if the right side needs to be evaluated in a scalar context. Otherwise, I might wonder which one you meant of: 
    my ($filemode) = ("immolate"); # list context

    [download]
    or 
    my $filemode = "immolate"; # scalar context

    [download]
    And yes, it really does matter when you get into subroutine arg grabbing, like 
    my $count = @_; # get the length

    [download]
    or should that have been 
    my ($count) = @_; # get the first arg

    [download]
    So, make your left side and your right side agree, and I don't have to scratch my head wondering where you are headed.

    -- Randal L. Schwartz, Perl hacker

[reply]
[d/l]
[select]
      Letting go of brackets is hard if you come from the C school of bondage and discipline programming, where forgetting something minor, like brackets on a function call, is punishable by death ("Segmentation fault.").

      When declaring arguments, I have found that the code looks strange, inconsistent, and a little off-kilter when mixing and matching declaration styles, where 'off-kilter' is a euphemism for "looks broken": 
         sub Foo
   {
        # Arguments: ARRAY <- ARRAY
        my ($ich, $bin) = @_;

        # Local variables: SCALAR,SCALAR,...
        my $x, $y, $z;

        # Local constants: ARRAY <- ARRAY
        my ($ein, $berliner) = qw [ jelly donut ];

        # Single constant: SCALAR <- SCALAR
        my $go = 5;
   }

      [download]
      Any statement like 'my $count = @_' can make me feel a little bit dizzy, if only because it seems like anything could happen there (i.e. concatenation with spaces, concatenation without, first element assignment, last element assignment, count of items, index of last item, etc.). Instead, I would rather explicitly specify what is intended as 'my ($count) = scalar (@_);', though rumor would have it that 'scalar' is deprecated.

      Anyway, maybe I'm just behind the times. I use brackets on int() and join(). I'll admit it! Maybe it's curable. As long as I'm careful to make sure that my assignments are array-safe (as I don't want to go to jail) then things work okay, in their own wacky way, and everything is bracketized and compartmentalized neatly.

      So, I can only suppose that you would prefer the following mutant variation, suggested for fun: 
           my $filename = "/path/to/file",
        $filemode = "immolate",
        $opmode   = "seek",
        $filetype = "image/gif";

      [download]
[reply]
[d/l]
[select]
        Hmm. Nope, you ended up with a few broken ones: 
        # Local variables: SCALAR,SCALAR,... 
my $x, $y, $z; 
...
my $filename = "/path/to/file", 
        $filemode = "immolate", 
        $opmode   = "seek", 
        $filetype = "image/gif";

        [download]
        Neither of those declare locally anything but the first var. You'd have to do something like: 
        my $x, my $y, my $z;

        [download]
        Just think of my as a really high precedence prefix operator that must appear before an lvalue, and you'll have the right mental model. But to figure the scalar-vs-arrayness of the rest of the expression, throw away all the my's first.

        My preference is one variable per my declaration, unless it's a bunch of scalars and an optional terminating array being fed from a list (like a subroutine argument grab).

        -- Randal L. Schwartz, Perl hacker

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom