Just across the hall from m// is s/// ...
Considering the semantics of m// and especially s/// at the user level, we'll probably[*] want to take snapshots of dynamic strings (think P5's "FETCH" or overload '""'), and apply all the pattern operations to that snapshot. *However*, in the usual case of applying the pattern to a simple string, we want to avoid the overhead of making a copy. This may imply an API requirement.
Yeah, we need a bit more information tacked onto PMCs -- whether they can return a STRING that properly represents them or not. (PMC strings with pieces in different encodings, or with annotated text, wouldn't be able to)
The plan here is for PMCs which can provide a STRING to do so, with the regex code then grovelling over it. On completion we call the set_string vtable method to put the resulting string back.
PMCs which can't then get iterated over much more slowly, probably pulling characters out one by one. For these, the example you gave:
[*] Unless it's a _feature_ that given tied $a,
($a = "aaa") =~ s/a/b/g
would call STORE four times ("aaa", "baa", "bba", "bbb").
would call STORE four times. (Though I think all of perl 5's tied variables would be able to return a string rep, so you'd get STORE, FETCH, STORE called_
I think in all cases we'd get a new string out of a PMC, but since it's a COW version it'd be reasonably quick to do so. OTOH, I can certainly see the utility of returning the actual underlying string if we can, to avoid having to copy data. Hrm. Gotta think on how that should look a bit.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
