I'm going to start working on an AbstractPMCArray PMC class that can provide some default array vtable functions for other PMCs to inherit. This will give array classes some functionality for free. AbstractPMCArray will implement splice, for example, which can be implemented using an array's external interface.
I would like to add some sort methods as well: quicksort(), mergesort(), etc. But as methods, there is potential for these to end up in a user-visible space. Say for example, that I add a mergesort method to AbstractPMCArray. Ruby's array class wouldn't be able to use AbstractPMCArray as a base class because there is no mergesort method on an Array in Ruby. Tcl has it easy because there's no OO support (everything is a string, not an object). So we're mainly interested in adding methods that make our lives easier and don't have to worry about user-visible methods. And I can imagine that other compiler writers would want to use methods like these without having to expose them. One possible route is two implement two classes: an AbstractPMCArray class that only provides vtable functions and an AbstractPMCArrayWithMethods class that inherits from AbstractPMCArray and adds methods into the mix. But then there's also the question of how FixedPMCArray and ResizablePMCArray should behave. Should they have methods on them (which will be user-visible)? They do right now, but that's not correct if compiler writers are expected to use these as the basis for their array classes. Would these each need to be split into 2 classes as well? If so, we'd want to make multiple inheritance really work with PMCs. Any thoughts? -- Matt Diephouse http://matt.diephouse.com
