[ruby-talk:02679] Re: Append alias for Array.append?

> (Posted on comp.lang.ruby and ruby-talk ML.)
>
> Aleksi Niemelwrites:
>
> > Hideto ISHIBASHI:
> > >I don't know whether Array should has the `append' method.
> > >BTW, what is the opposite of `append?'
> > >Array.push <---> Array.append
> > >Array.pop  <---> Array.???
> >
> > Good point.
> >
> > Maybe there should be some Array.remove_from_end but there's two
different
> > view points here.
> >
> > push/pop is used when Array is viewed as a stack.
> > append/remove_from_end as a array or vector.
>
> From the algebraic data structure perspective, stacks and vectors are
pretty
> much the same thing.
>
> Speaking of two points of view here, I just noticed that it is very ironic
> that append/remove_from_end are a *horizontal* view (with respect to text
> operations or Lisp list operations), yet arrays or vectors in math,
physics,
> and engineering are commonly written and visualized *vertically*. To my
> former semi-engineering-mathematical soul, to use append/remove_from_end
> from an array or vector is incongruous and discordant.
>
> I'd prefer to stick with the briefer push/pop terminology, to facilitate
> easier understanding of each-other's programs, and to not complicate the
> language when the payoff is not clearly positive for most people.
>
> While it may be nice to make things easy for Python converts, the Perl
> community is vastly larger and probably ought to take priority, and it is
> used to push/pop.
>
> > Well, the opposite of Array.append would be Array.prepend, just an
> different
> > axis :).
>
> I hope you really meant to say j"ust a different (-: inverse)
*direction*".
>
> > While we are on it, maybe Array should implement more than Enumerable.
> Maybe
> > there's need for module Stack where push and pop are coming from, and
> Vector
> > where append etc. reside.
> >
> > I think Java uses Vector.addElement, .removeElement.
>
> I'd prefer not to propagate unnecessary complicating superficial
differences
> that were the unintended products of deep historical coincidences.
>
> Conrad
>
>
>
>
>