Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

@_0 vs. $_0

by princepawn (Parson)
on Nov 22, 2000 at 18:43 UTC ( #42923=perlquestion: print w/replies, xml ) Need Help??
princepawn has asked for the wisdom of the Perl Monks concerning the following question:

In some code I have to now maintain, I first turned on use strict and use warnings. Then the following warning came up: Scalar value @_[0] better written as $_[0]

the error corresponds to this line:

( $paramName, $paramValue ) = split /=/, @_[0], 2;

My thinking on this code is that @_[0] creates an array slice consisting of the first element of @_. This array slice is a list, but is forced into scalar context because it is the second argument of split. Forcing a list into scalar context returns its last argument, which is the only argument in this case. Thus we would've been better off writing $_[0]

Sound good? I have to make this code change and justify it on this code which has had many years of comfortable use without use strict or use warnings. Any code change I make has to be rigorously justified, thus I want to 100% sure of what I am saying.

Replies are listed 'Best First'.
Re: @_0 vs. $_0
by merlyn (Sage) on Nov 22, 2000 at 18:46 UTC
    Yes, almost always, @foo[$bar] is broken, and should have been written $foo[$bar]. In many cases, this is an undetectable mistake, as in:
    $total = @a[3] + @a[4]; # works print @a[5]; # works
    But is fatal when we use it in a place where it makes a difference:
    @a[3] = <STDIN>; # read one line? NOPE!
    Hence the very right warning.

    -- Randal L. Schwartz, Perl hacker

Re (tilly) 1: @_0 vs. $_0
by tilly (Archbishop) on Nov 22, 2000 at 18:47 UTC
    Yes, this is right. In fact I recommend typing "perldoc perldiag", looking for the string "better written", then cutting and pasting the message out of perldiag directly into your explanation.

    In fact this is a good approach with anything turned up by warnings, all of the messages are in perldiag along with explanations of why the message is considered a potential error.

      Or add:
      use diagnostics;
      or add -Mdiagnostics to the command line. In either case, you can be really lazy, because the right part of the manpage is pasted right at ya!

      -- Randal L. Schwartz, Perl hacker


        I am plotting to get people to browse perldiag and learn the keystrokes to move quickly through manpages. Why do you have to ruin it by giving them the shortcut? :-)

Re: @_0 vs. $_0
by Dominus (Parson) on Nov 22, 2000 at 19:14 UTC
    princepawn says:
    > This array slice is a list, but is forced into scalar
    > context because it is the second argument of split.
    The second argument to split is not in scalar context. It is in a list context. There is no Perl function whose second argument is in scalar context.

(tye)Re: @_0 vs. $_0
by tye (Sage) on Nov 22, 2000 at 20:32 UTC

    Forcing a list into scalar context returns its last argument,

    Um, no. Make that NO. (:

    Constructs that would return a list of scalars if used in a list context may or may not return the last scalar of that list if used in a scalar context.

    I choose that wording very carefully as the word "list" is not narrowly defined for Perl and can mean any number of things (despite the fact that "scalar", "scalar context", and "list context" are all clearly defined for Perl).

    Many constructs do behave this way (one reason for the persistent nature of this myth). In particular, an array slice behaves precisely this way. So, if you actually did have a scalar context here, then your conclusion would be correct even though your reasoning was flawed.

            - tye (but my friends call me "Tye")
Re: @_0 vs. $_0
by princepawn (Parson) on Nov 22, 2000 at 18:54 UTC
    Well, it took two lumps over the head before I got it but now the required suite of uses on all code I write is:
    use Data::Dumper; use strict; use warnings; use perldiag;

    But the beginning book I learned from was in Perl 4, and I assume that was why it did not have these uses as paramount. Come to think of it, very few books I own make a point of including these highly important standard modules.