My suggestion was to try to find a more comfortable method name (to me, and
maybe also to some people) for 
"unshift", (while shift is from shell, unshift is Perlitical, to my knowledge).
Since "slice" methods are going to be added, the ambiguity could be less
for using pop(index=-1) and push(obj,index=-1) once documented,
(Or "insert(index , obj) may look better?)

Thanks

-Ted


> In message "[ruby-talk:01347] Say Hi"
>     on 00/02/15, Clemens Hintze <c.hintze / gmx.net> writes:
> 
> |I beg pardon, but I would not like it! I think it is not too good to
> |have too multifunctional methods. Every method should has its
> |behavior. push and pop are used to handle an Array like a stack not
> |for indexing it. shift and unshift do the same but from the opposite
> |end. They are not necessarily coming from Perl. Nearly all UNIX shells
> |treat them like Perl. I assume Perl has taken that behavior from the
> |UNIX shells.
> 
> A few months ago, a proposal to make pop(n) to pop out n elements in
> array is proposed in Japanese list.  We discussed it, and abandoned
> for argument ambiguity.  Ted's proposal confirms it.
> 
> |IMHO, it would be better to allow Array::delete_at to receive also
> |negative arguments like Array::[]. If it would do, it would really be
> |what you want to have.
> 
>   def slice!(*args)
>     result = self[*args]
>     self[*args] = []
>     result
>   end
> 
>   def slice(*args)
>     self.dup.slice!(*args)
>   end
> 
> 
> 							matz.
>