So, this divides anything that provides an array like interface into two camps - those that support the push opcode, and those that don't. This means that whenever you write code that needs to be PMC agnostic (for example, any of the list processing commands in Tcl - after all, the could be called by someone elses languages, and I don't know if their arrays are resizeable), you have to avoid using push when implementing the code. Or, handle the exception and the fallback to a non push method of doing it (which seems like even /more/ work.)
If nothing else, this should probably be documented in stronger language in ops/pmc.ops. (Similar additions should probably be added for the other list manipulation opcodes as well) Though I'd be curious if a patch would be accepted to make all the array pmcs in classes/* support this.
Index: pmc.ops =================================================================== RCS file: /cvs/public/parrot/ops/pmc.ops,v retrieving revision 1.27 diff -b -u -r1.27 pmc.ops --- pmc.ops 3 Sep 2004 09:27:21 -0000 1.27 +++ pmc.ops 6 Oct 2004 12:33:21 -0000 @@ -338,6 +338,8 @@ =item B<push>(in PMC, in PMC)
Push $2 onto the end of the aggregate PMC $1, if that operation is defined.
+Note that this opcode is only defined for I<resizable> array PMCs, not +I<fixed> size array PMCs.
=cut
Leopold Toetsch via RT wrote:
Will Coleda <[EMAIL PROTECTED]> wrote:
Shouldn't this push just like PerlArray except with bounds checking?
Fixed means really fixed for that PMC. BTW you can't push onto an Array PMC either. Just use a ResizablePMCArray.
leo
