Front page | perl.perl6.internals |
Postings from June 2001
> >What do you mean by character size if it does not support variable length? > > Well, if strings are to be treated relatively abstractly, and we still want > to poke around through the string buffer, we need to know how big a > character is. I agree on this. I think support variable length encoding should be included. > I'm thinking locale is, in some ways, like tainting where it's really a > property of the data rather than a property of the code region. I think you misunderstand my point. It is "a property of the code region", but "a property of the context in which is the code is running". For example, Taiwanese read traditional chinese characters, but PRC people read simplied chinese. Even we take the same data, and same program (code), people just read differently. As an end user, I want to make the decision. It will drive me crazy if Perl render/display the text file using traditional chinese just because it was tagged as "Big5". > Yep, I fully agree. (Well, I'm not sure of the ASCII restriction on the > name, but I can live with that as a lowest-common-denominator > sort of thing) > >The byte based is more useful. I have utf-8, and I want to substr it > >to another utf-8. It is painful to convert it or linear search for > >charaacter position. > > The pain is the reason for specifying it in the API. If we force the pain > to be local to the encoding then it means that we don't have > to embed it in the core. If it is common API, I like to specify it in core, so each encoding implemetation can strictly follow. I believe it is common enough. HongThread Previous | Thread Next