On Thursday 27 March 2008 18:20:21 Patrick R. Michaud wrote: > Actually, it can be done without subclassing via the following > > .namespace [ 'ResizablePMCArray' ] > > .sub 'unshift' :method > .param pmc list > .param pmc value > unshift list, value > .end > > .sub 'shift' :method > .param pmc list > .param pmc value > shift list, value > .end > > > I've already commented that perhaps these should be a built-in > part of the ResizablePMCArray in Parrot. However, if that's > not likely to happen, then perhaps either PCT or NQP should > go ahead and provide them, so that they're available whenever > PCT is loaded. But part of me feels that adding methods to > ResizablePMCArray is a little out of NQP's scope. > > So, our choices become: > > 1. Have NQP automatically recognize shift/unshift/push/pop > as "special functions" (keywords) and map them directly to > Parrot's shift/unshift opcodes.
That's not too bad, but I'd like to reduce the amount of special magic in Parrot as a general rule. > 2. Add shift/unshift/push/pop methods to ResizablePMCArray > (or one of its superclasses) in Parrot This is my preference. It feels like a role. > 3. Have PCT and/or NQP supply the shift/unshift/push/pop methods. > > 4. Have PCT and/or NQP define their own "List" subclass > that provide shift/unshift/push/pop (this could conflict with > "List" classes in other languages). Conflicts are no fun. -- c
