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

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]

Replies are listed 'Best First'.
Re: Re: scalar my vs list my
by merlyn (Sage) on Apr 27, 2001 at 01:50 UTC
    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]
      At the risk of straying further, its ok to do this isn't it: 
      my ($filename, $filemode, $opmode, $filetype) = 
    ("/path/file", "immolate", "seek", "image/gif");

      [download]
      Ignore me: I really should get into the habbit of reading the last paragraph of peoples' posts.

      $ perldoc perldoc
[reply]
[d/l]
        What about this unruly specimen: 
           (my ($filename, my ($filemode, my ($opmode, my $filetype))))
   = "/path/file",    "immolate",      "seek",  "image/gif";

        [download]
        The one thing that has bugged me about my() was the way it used to cling to the real block, and not the virtual block. As in: 
            for (my $n = 0; $n < 100; $n++)
    {
        # ... (Stuff)
    }

    # ... (More Stuff)

    for (my $n = 0; $n < 100; $n++)
    {
        # ... (Stuff)
    }

        [download]
        IIRC, there used to be a condition that generated an error for the second declaration. This seems to have been fixed, thankfully.
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom