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

Conrad:
> 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.

This is true and something I can't value easily. It's great to have you
people around.

> 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.

Actually I'm coming more from the Perl world and Array.append suits me way
better than push, which I would use only when I think I'm working with
stack.

The stack metaphore works well when you insert more data to your structure.
But it fails with big bang when you use the same datastructure few lines
below in an ordered loop like

  @array = ($foo);
  $stack = \@array;
  push( @{$stack}, $bar );  
  for $obj (@array){ }

or even worse, accessing it randomly.

If there's no 'append' I would use '<<' but it doesn't have OTOH the same
functionality. array.append(1,2,3) should be array << 1 << 2 << 3. (And then
one more point is the readibility issue for newcomers from C++ world ;=).

So I'd forced to use push, just like with Perl :).

> 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*.


Excellent point. This topic has been under looking glass earlier too. And if
Ruby seeks some point of reference or just plain excellence here, APL would
be the way to go. (If I recall correctly.) One of APL's not so joyful sides
were the fact that some quite experienced coder could try to figure out four
hours for four lines of code. Well, for some people that is about the best
use for freetime ;-).

For 'prepend axis' Conrad comments
>  I hope you really meant to say just a 
> different (-: inverse) *direction*".

Yes, that's what I meant. Not actually real axis :).

> > 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.

I can't figure out which part you meant with 'complicating superficial
differences'. If it were for Java I agree. If you objected other
'interfaces',
like Stack, I would like to reconsider.

And now I see that I made big mistake here. I'm not totally familiar with
mix-ins yet, but when I wrote my mail I meant 'implement interface'.
Enumerable on the other hand is just a mix-in class providing nice
functionality which depends on class own functionality (like each).

While I think it's easier to say

class MyExtremelyComplicatedDataStructure < Weirdo
   # but don't be afraid, most of the time you can use 
   # this class as simply as a any Stack
   include_interface "Stack";
end

we bang our head to the wall, since we can only have mix-in classes or real
inheritance. Now, my class inherits already (so I can't inherit it
additionally from Stack-interface), and we can't make mix-in which requires
something simple from class (mix-in module function Stack.push calling
class' push is not reasonable).

So maybe you're right, there's no way to be explicit about underlying
interfaces. Thus MyExtremeExample can't act like a stack publicly, *stating
it*, for 

   def functionality_using( stack )
   end

	- Aleksi