push_integer() not implemented in class 'FixedPMCArray'

[Andrew Whitworth]

On Wed, Sep 9, 2009 at 1:59 PM, Andy Dougherty<doughera at lafayette.edu> wrote:
> I would think that all depends on how it's actually specified and
> implemented.  For the fixed-size stack model I described, I could easily
> imagine implementing the push/pop ops with lots of copying of elements,
> and no changes to any of the other operations on fixed-size arrays.  For
> those specific operations, performance wouldn't scale well with array
> size, but nothing else would be changed.

You're right, it really does depend on a lot of factors. I think if we
are going to end up with a data type that is a circular buffer or a
windowed type of stack, we should rename it to be more appropriate, or
add those other types separately, or whatever. In fact, I would be
very happy to add these kinds of things if people were interested.

The name "stack" or "queue" obviously carries with it a certain set of
expectations. However, I think the name "Array" has some expectations
as well: It's a data type that contains a set of like-typed items and
is indexed by integer key. There is no real reasonable expectation
that an "Array" is going to have all sorts of other operations or
mechanisms. I think it's probably a much better idea to implement a
new role, "stack" to allow push/pop/shift/unshift. It's also useful to
think that some languages have a "Stack" type that allows push/pop but
does not allow indexed lookups. Other completely unrelated types
(Context, for instance) will have push and pop operations, but aren't
arrays by any stretch of the imagination.

> Again, I don't have any particular point of view here.  I just want to
> point out that there is prior art.  One can sensibly apply the notions of
> push and pop to a fixed-size array.

Yes, it is a very good point and if there are compelling use cases I
think it would be good to add these things. Of course, there are
differences in how we would implement these, and I think we'd be
better off creating new types for these behaviors instead of
shoehorning our base implementation into one and letting people who
need something different to deal with it.

My suggestion, in a nutshell, is this:

1) Add a "stack" role, which comprises push/pop/shift/unshift. The
Resizable*Array Types will implement this but the Fixed* ones won't
2) If we need a fixed-size array type that implements stack
operations, we can subclass Fixed*Array and add custom behaviors.

I don't think this would require a deprecation cycle.


--Andrew Whitworth