Odd behaviour of ResizableWhateverArray PMC's

[Bruce Keeler]

On 10/8/2009 10:45 PM, Martin Kealey wrote:
> And thus began a debate: some hold that it's only a "low level buffer" and
> that initialization isn't guaranteed; others (like me) hold that this breaks
> a fairly fundamental guarantee.
>
> The claim that it's "low level" and therefore it should be "uninitialized
> because it's faster" doesn't fit with it being an arbitrarily resizable (*1)
> array. A primitive operation like "push" can take O(n) time to complete
> because it may result in the entire array being block-copied in memory. So
> complaining about potentially taking O(n) time to arbitrarily resize doesn't
> make sense.
>
>    
An individual push *might* require a copy and be therefore O(n), but 
most pushes won't.  Push overall should be amortized O(1), or there's 
something horribly wrong with the implementation.
> It's also inconsistent with ResizablePMCArray, ResizableBooleanArray and
> ResizableStringArray, which *do* reinitialize elements when the array is
> resized.
>    
Strings and PMCs are much more heavyweight than ints, and the 
consequences of dereferencing an arbitrary memory location are 
potentially severe.
> (*1: If the only way to extend such an array was by push and unshift, then I
> wouldn't have a problem, because there would be no way to create
> uninitialized cells. Alternatively, if we got rid of all the expensive
> operations -- including push, pop, shift, unshift and delete -- and just
> left a raw buffer, then I'd be happy too, although I'd probably turn around
> and want to build full-feature versions as well.)
>
>    
delete and shift should be the only expensive ones there.

I'm not opining either way on the question at issue here, but examining 
the existing code out there to determine how these PMCs are actually 
being used would probably be a useful guide as to what to do.

Bruce