On 15/10/14 10:04, Rowan Collins wrote:
Rowan,
As I said at the top of my first post, the important thing is to capture
what those requirements actually are. Just as you'd choose what array
functions were needed if you were adding "array support" to a language.
I'm sorry for not making myself clear. What i'm essentially saying is
that i think "noël" test is synthetic and impractical, it's also
solvable with requirement of NFC strings at input and this is not
implementation defect. I also believe that Hangul is most likely to be
precomposed and will work alright. And i have another opinion on UTF-8
shortest-form.
This is my personal opinion of course.
That aside.
I think requirements is what i was asking about, i'm assuming that your
standpoint is that string modification routines are at least required to
take into account entire characters, not only code points. Am i correct?
What is confusing me is that i think you're seeing it as a major
implementation defect. To avoid arguable implementations, i've made
short example in Java:
System.out.println(new StringBuffer("noël").reverse().toString());
It does produce string "l̈eon" as i would expect. Precomposed "noël" also
works as i would expect producing string "lëon". What do you think, is
this implementation issue or solely requirements issue?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
