Seems like the results of
@b = 1 .. 10;
for ( 1 .. 3 )
{ push @a, pop @b;
}
and
@b = 1 .. 10;
push (@a, pop ( @b, 3 ));
But this RFC makes it seem like they produce different results in @a. One could
argue that the current definition of unshift has a similar problem, and that you
are "preserving" that behavior. i.e. shouldn't:
unshift ( @a, 1, 2, 3 );
produce the same result as
for ( 1 .. 3 )
{ unshift ( @a, $_ );
}
So while your proposed pop and the current unshift can be easily defined in terms
of splice, I think that produces unexpected results.
I'd like to see this RFC modified so that both the above two sequences are
equivalent. p52p6 can convert
unshift @x, ...
to
unshift @x, reverse ...
and all will be well.
> What should happen when the expression given to C<pop()>, or
> C<shift()> evaluates to a negative number? I see three options:
>
> 1) Nothing. We can only pop/shift positive amounts
> 2) Act as if the number were positive (i.e. pop @array, abs(EXPR))
> 3) C<pop()> would then act as C<shift()> and C<shift()> would
> act as C<pop()>
>
> The responses to this RFC so far haven't seen any consensus on this
> matter (unless you call one person voting for option #3 a consensus).
> However, I propose that option #3 be adopted since it seems the most
> Perlian to me.
I like #3 too, does that make a better consensus?
--
Glenn
=====
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
____________NetZero Free Internet Access and Email_________
Download Now http://www.netzero.net/download/index.html
Request a CDROM 1-800-333-3633
___________________________________________________________
