Leopold Toetsch wrote: Not having an INTERP argument severely limits us, even in other ways.
The INTERP argument is fine. The user defined encoding is/was my problem.
Similarly, that would eliminate the chance of a STRING* which is actually a lazily concatenated list of other STRING*s; we'd only be able to do this as a PerlString derivitive.
I have problems imaginating such kind of STRINGs. They need an attached PMC doing the work + an attached list containing the string chunks. You need a PMC anyway. Why not have this in a PerlString derived class. So you don't have an overhead on "average" strings.
In particular, if we make a STRING* encoding which is a lazily concatted list of other strings (yes I keep going back to it, but Larry said we'll have them. Theoretically he might have only meant as a high level type (a PerlString derivitive) but *I* think it would be nice for to be able to have this as a STRING* type) we'd want our iterator to be two integers: the first one being the integer into our array, the second being the iterator into the string we're currently iterating through.
How many strings in JAPP[]1 might need that? Do you really want to slow down all string access, just for one very special corner case?
Ok. I see. That's fine - except for utf8 strings.... provide wrappers which take character index arguments, and converts them into string iterators relative to those particular strings.
Why wouldn't it work for utf8 strings?
The wrapper is O(n) for utf8 strings. So converting once might be cheaper during the first character-index access.
leo
JAPP Joe Average Perl Program
