in reply to Re^4: why does push not default to $_? (simple)
in thread why does push not default to $_?

I tried a prove of concept of overiding push, such that a missing second parameter defaults to $_. 
use subs 'push';

my @a;
$_="x";

# push @a;  # Error: "Can't use an undefined value as an ARRAY referen
+ce ..."
print @a;

# Override!
sub push (\@_;@) {
  CORE::push( @{+shift},@_) ;
}

push @a;
print @a; # prints "x"

@b=("y","z");
push @a,@b;
print @a; # prints "2"

[download]
So it's possible to use push defaulting to $_, but a second Array to push will be forced into scalar context! 8(

So the prototypesymbol _ doesn't work with parameterlists ...

Cheers Rolf

Replies are listed 'Best First'.
Re^6: why does push not default to $_? (simple)
by JadeNB (Chaplain) on Dec 07, 2008 at 18:13 UTC
    I know that it doesn't have the elegance of what you're looking for, but why not just build in the default? 
    sub push (\@;@) {
    CORE::push ( @{+shift}, @_ ? @_ : $_ )
}

    [download]
    (Incidentally, this works for me, but is it guaranteed to do so? I seem to remember—but can't find—a discussion here a while back indicating that, while arguments are often evaluated left-to-right, they aren't guaranteed to be. Do we know that the shift will happen before we test the value of @_?)

    UPDATE: LanX points out an extremely good answer to “why not?”, namely, “Because it behaves like accessors that get/set based on whether they have/don't have an argument, and passing an empty list leads to surprises.”

[reply]
[d/l]
[select]

      Operands are evaluated left-to-right except for assignment operators. Even right-associative ** evaluates its operands left-to-right. It's not documented, but I don't see it changing. From what I've read, I'd even say there's a desire to fix a case where it isn't, should one be found.

      If you wanted to avoid relying on the undocumented feature, you'd do 

      sub push (\@;@) {
    my $array = shift;
    CORE::push ( @$array, @_ ? @_ : $_ )
}

      [download]

      Of course, both yours and this modified version fail to handle @b=(); push @a, @b; properly.

[reply]
[d/l]
[select]
      sub push (\@;@) {
    CORE::push ( @{+shift}, @_ ? @_ : $_ )
}

      [download]
      already tried it, it's a trap forget it. If you do push (@a,@b) and @b is empty, then $_ will be pushed, and that's definetly not what you expect!

      If there is any feature request, which might make sense on the wishlist for the next perl5 version, it's to add a prototype symbol for "list defaulting to $_". "_" is already a symbol for "scalar defaulting to $_" which must be placed as last symbol before ";".

      So I suggest double underscore "__" shall mean "list defaulting to $_".

      I remember slightly that in PBP one can find a somehow similar reasoning why not to use prototypes! *

      If anybody knows a way to already implement push() this way, please try these testcases: 

      use subs 'push';

sub push (\@;@) {
#  print $_[0],$_[1];
  CORE::push( @{+shift}, $_[0]? @_ :$_) ;
}

$\="\n";

my @a;
$_="_";




print "--- one parameter";
push @a;
print @a;

print "--- long list of parameters";
@b=("x","y");

@a=();
push @a,@b;
print @a;

print "--- one element";
@a=();
push @a,"z";
print @a;

print "--- one element list";
@a=();
@b=("z");
push @a,@b;
print @a;

print "--- empty list";
@a=@b=();
push @a,@b;
print @a;

__END__
--- one parameter
_
--- long list of parameters
xy
--- one element
z
--- one element list
z
--- empty list
_

      [download]

      Cheers Rolf

      UPDATES: Chapter9 "Subroutines"/Subchapter "Prototypes" -> "Don't use prototypes" ... The examples show that they mostly confuse because they often force scalar context!
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom