Benjamin Goldberg <[EMAIL PROTECTED]> wrote: > There are a number of shortcomings in the API, which I'd like to address > here, and propose improvments for.
> To allow user-defined encodings, and user-defined transcoding, (written > in parrot) the first parameter of all of the function pointers in the > ENCODING and TYPE structures should be INTERP. This belongs IMHO into PerlString (or better a class derived from that). > I *really* *really* want string iterators. The current API for > iterating through the characters of a string is, IMHO, vastly > insufficient. encoding->skip_forward(.., by_n) doesn't look like that insufficient. A skip_one() function wouldn't harm though. > 1/ Iterators won't become invalid if the string gets moved in memory. > Currently, all we've got is a void* pointer which points into the buffer > of the string; during GC, strings can get reallocated, making the > pointer invalid. You are not allowed to cache the pointer. string->strstart + idx is always your actual character in the string. To satisfy 1/ we would have to mark the string as "immobile" (which we have a flag for) *but* you can't grow such strings, the copying collector can't cleanup the block, where the string is in (and worse, the collector currently just frees the block). > 10/ Add methods to PerlString to make it compatible with Iterator. Yep. That was in my iterator proposal. > 11/ Any string_ function which takes a character index as a > parameter, should be able to take a string iterator. Bloat IMHO. While this abstraction is flexible, it IMHO doesn't belong into the string subsystem but into a string class, that implements these functions. > 12/ The rx engine should use the new ops. > 12a/ We should be able to use the rx engine to "match" a stream of > values from an Iterator PMC. Whether this Iterator is crawling over a > PerlString, or PerlArray, or something else, shouldn't matter to the rx > engine. That's fine, we are at classes level here. leo
