Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>>
>> 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).
> Then how do we pass a user-defined string to a function which expects an
> argument in an Sreg?
We have here IMHO the same relationship as with ints:
int (INTVAL) <-> Int (PerlInt)
str (STRING) <-> Str (PerlString)
You can't tie native types, you can't attach properties on these and so
on. And you can't pass some kind of active native strings in the SReg.
The user-defined (written in parrot) implies, that these are
PerlString PMCs.
> Now, suppose that instead of a pointer, we had an integer describing the
> number of bytes from strstart to where we're looking... *now* most of
> the problems go away.
So lets change the encoding->skip_{for,back}ward to take/return an
INTVAL being the byte-position relative to strstart.
>> > 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.
> The bloat can be avoided if the primary string_ implementations *only*
> took string iterators. Then, to satisfy those who want to use character
> indices, provide wrappers which take character index arguments, and
> converts them into string iterators relative to those particular
> strings.
Ok. I see. That's fine - except for utf8 strings. But these could be
converted to utf32 as soon as they are seen.
leo
