Equally old are the NextStep Object C functions which are now embodied within MacOS X. It might also be informative for us to see what's done there. On 8 December 2015 at 23:50, EuanM <euanmee@gmail.com> wrote:
Dale,
yes - sorting based on the value of codepoints is almost always guaranteed to be wrong. Sorting is an application-specific issue, not a technical Unicode issue, as there is more than one canonical sort order per culture, and there is often more than one culture per writing system.
e.g. ISO Latin 1 / Latin 9 covers these cultures (amongst others) English (2 sort orders); Spanish; French (2 sort orders); German (2 sort orders); Swedish; etc
German sort order differs from Swedish for the same characters, etc
Todd,
My thinking is that if we implement fully-composed strings as heterogenous arrays, we sidestep a lot of the complexity of the ICU.
If it turns out that the performance is terrible, we can then seek to incorporate the ICU.
On 8 December 2015 at 22:36, Todd Blanchard <tblanchard@mac.com> wrote:
I just want to second Dale's endorsement of the ICU library. It has been around a long time (originally developed by Taligent) and it provides the base unicode capabilities for an awful lot of software.
I think it would make more sense to bring icu into Smalltalk as a NativeBoost library than to spend resources reimplementing and maintaining it.
-Todd Blanchard
On Dec 8, 2015, at 11:20, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
On 12/07/2015 11:31 PM, H. Hirzel wrote:
Dale
Thank you for your answer with links to the ICU library and the notes about classes in Gemstone. Noteworthy that you have a class Utf8 as a subclass of ByteArray.
I understand that Gemstone uses the ICU library and thus does not implement the algorithms in Smalltalk.
I am currently looking into what the ICU library provides.