in reply to Re: printing a scalar as an array
in thread printing a scalar as an array

Very nice. Two things

1) use the strictures

2) if you use perl -l flag in the shebang you can avoid newlines at the end of your prints. 

#!perl -l
use strict;
use warnings;

my @array1 = qw(1 2 3 4 5);
my @array2 = qw(a b c d e);
my @array3 = qw(6 7 8 9 0);
my @array4 = qw(f g h i j);
while (<DATA>)
{
        foreach (eval("$_"))
        {
                print "$_";
        }
        print '';
}
__DATA__
@array1;
@array2;
@array3;
@array4;

[download]

UPDATE: I semi-agree with dragonchild. Personally, I just recently have been learning about the command line flags, and I have a lot of scripts where the "\n" everywhere does annoy me a bit, and I like not having to do it anymnore. But OTOH it is a bit obfu.

UPDATE2: Dragonchild opined to me that "command line switches are for use in the command line" which on reflection seems reasonable enough. So if you agree with this point of view, delete the shebang line (#!) and just call the script using "perl -l". I think I may adopt this approach myself.

Update3: (Red in the face) All right, all right! Save the -l for one-liners. Never mind.

Replies are listed 'Best First'.
Re^3: printing a scalar as an array
by dragonchild (Archbishop) on Feb 23, 2005 at 13:05 UTC
    Somedays, I wish I could both ++ and -- a post. (Guess which one I ended up doing ...)

    Yes, use the strictures. But, don't use the commandline flags in a production script! Good Gods, man, are you trying to get the OP to write obfuscated code?!? Who looks at the shebang line? If I were to read that code, I would be going bonkers trying to figure out how the newline was getting in there, and I golf with -l on a regular basis. (He shoots a 14 handicap, in case you're wondering.)

    Being right, does not endow the right to be rude; politeness costs nothing.
    Being unknowing, is not the same as being stupid.
    Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
    Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

[reply]
      But, don't use the commandline flags in a production script! Good Gods, man, are you trying to get the OP to write obfuscated code?!? Who looks at the shebang line?
      Well, I think that -l is safe enough in short enough scripts. So it all depends on how short the production script will be, and of course a "production script", whatever it could be, tends to give the idea of being a rather longish thing, or if it is not, it's still likely to grow into one, so I think that you're right in the vast majority of cases.

      I think I have a tendency to overuse -l myself, because I like not to have to include literal newlines. But then when I want both this and to be safe I do 

      {
    local $\="\n";  # or $/, if it's not been changed...
    print whatever;
    print something_else;
    # ...
}

      [download]

      Of course if we had Perl6's say() we wouldn't be bothered, but then someone will certainly point out that we already have a module for that. OTOH, IMHO it could easily leak into the core in some next major perl5 release, couldn't it?

[reply]
[d/l]
[select]
Re^3: printing a scalar as an array
by Anonymous Monk on Feb 23, 2005 at 13:56 UTC
    Using the stricture adds, uhm, exactly nothing at all to the above program. It just increases the size of the program text. As for adding -l, I tend to only do that for only liners - with normal programs, you just want to use 'print' without newlines often enough to make it a nuisance (it's still possible by using printf though). I disagree with the remark in update2 though. "Just calling the script using 'perl -l'" is a major PITA. You want to call program by just typing their file names, having to remember which interpreter they need is hard - and it's even harder to remember which program needs which command line options! Not to mention that that will make debugging even harder than having -l mentioned in the she-bang line - that's easier to spot than the -l enforced on the program from the outside.

    However, I only write this node because of something else. What's with the quotes around $_ in the print statement? If you're going to nag about (pointless in this case) missing "use strict" statements, and whether or not to use -l vs. a newline, you should at least get rid of the not needed quotes around the variable.

[reply]
[d/l]
      "use strict" is not an option - it's a way of life!

      I would much rather see nagging (if I have to see nagging) about use strict than quotes around a $_ which will not add any overhead (?)

      Update: As for the 'perl -l' - I would lean away from that, but I have no real reasons I could back up. Why not just ($\="\n") ?
      --------------
      It's sad that a family can be torn apart by such a such a simple thing as a pack of wild dogs
[reply]
        Update: As for the 'perl -l' - I would lean away from that, but I have no real reasons I could back up. Why not just ($\="\n") ?

        For the same reason that you shouldn't say something like: 

        *CORE::log = sub {
    # Your logging code here
}

        [download]
        in some module buried three layers deep in your application infrastructure, just so you can write 
        do_some_operation( @args )
    or log( "some_operation() failed with @args!" );

        [download]

        Can you see the problem? What about if I wanted to add some mathematical functionality to this application that required the use of logarithms and the log() builtin function?

        The point is that you never want to violate the "Principle of Least Surprise". There are many, many community expectations in terms of how code will behave. One is that print() does not append a newline. If it suddenly starts doing so, I know I'd get very confused and spend a lot of time trying to figure out why. Modifying $\ or adding -l to the commandline is a very quiet way of making a very large global change that will confuse people who try and read your code, especially after you no longer work there.

        Remember - your code belongs to your employer and you have a responsability to make sure that maintenance of said code is as cost-efficient as possible.

        Being right, does not endow the right to be rude; politeness costs nothing.
        Being unknowing, is not the same as being stupid.
        Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
        Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

[reply]
[d/l]
[select]
        It's not the overhead. It's a bad habit. And eventually, it will bity you. People that tend to pointlessly quote scalars (and you see it happening not just with print, but with other function calls as well), will also quote them when the scalars happen to be refs. Oops. That's to reason to "nag" about use of quotes.

        As for not using $\ = "\n", to do it right, you'd have to do it each time before a print, and do it localized, or some other part of the program might act unexpectedly.

        If you don't want to type the "\n", use Perl6::Say (or whatever it is called), or use something like: 

        sub printnl {print @_, "\n"}

        [download]
        (although you won't be able to print to a filehandle that way).
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom