Leopold Toetsch wrote:
Is there a design reason for not having a chunked implementation?
Then you could use Array/PerlArray anyway (modulo the PerlUndef).
As I understood it, the language specific PMCs are planned to become dynamic classes and are supposed to move to their respection languange/* directory.
So that would leave the standard PMCs, from pdd17, in the core Parrot distribution. I'm not sure where the Array PMC stands there. My idea was that PerlArray should inherit from ResizablePMCArray.
This would make the Array PMC obsolete. Or a new incarnation of the Array PMC could serve as an abstract PMC.
I imagine a 'extends' hierarchy of PMCs like:
Default | +------------------------+---------+--------+-------+ | | | | Hash Array Integer Float | | +--+-----+ +---------------+-----------------+ | | | | | TclHash PerlHash FixedIntegerArray FixedFloatArray FixedPMCArray | | | ResizableIntegerArray ResizableFloatArray ResizablePMCArray | +---+----+ | | TclArray PerlArray
I left out the Boolean, String, Env, ..... PMCs.
This also depends wether there will multiple inheritance for C-Code generation with 'pmc2c2.pl'.
One thing, that is propably hard to cover, is the method "sort" inherited from FixedPMCArray. It looks like 'qsort' needs a continous piece of memory for sorting.
Well, qsort can't remain for various reasons. The main one is that it doesn't allow additional params to be passed to the sort function. Currently these are static globals, which makes the sort non-reentrant.
So I don't have to worry about it.
For performance reasons we might need some sort/merge algorithm anyway and then it can work through chunks too.
CU, Bernhard
-- ************************************************** Dipl.-Physiker Bernhard Schmalhofer Senior Developer Biomax Informatics AG Lochhamer Str. 11 82152 Martinsried, Germany Tel: +49 89 895574-839 Fax: +49 89 895574-825 eMail: [EMAIL PROTECTED] Website: www.biomax.com **************************************************
