David Mitchell <[EMAIL PROTECTED]> writes:
>
>Personally I feel that that string part of the SV API should include most
>(if not all) string functions, including regex matching and substitution.
What are string functions in your view?
m//
s///
join()
substr
index
lc, lcfirst, ...
& | ~
++
vec
'.'
'.='
It rapidly gets out of hand.
Why not eval "$string" as well ? ;-)
then in the limit perl can just become eval scalar(<ARGV>);
Seriously - I think we need to considr the original question
"What is the representation" based on perl5 hindsight, then think what
operations we want to perform on it, then divide those into the ones
which make sense to be "methods" (vtable entries) of string,
those that are part of string API, and those which are just ops messing
with strings.
>That way way there can be multiple regex implementations to handle different
>cases (eg fast one(s) for fixed width ASCII, UTF-32 etc, and a slow horrible one
>for variable-length UTF-8, etc). Of course perl itself could provide a default regex
>engine usable by all string types, but implementors would then be free to add
>variants for custom string types.
I would argue one does that by making the regex API more modular.
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
