<div dir="ltr">Hi Dale,<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 10, 2015 at 12:27 PM, Dale Henrichs <span dir="ltr"><<a href="mailto:dale.henrichs@gemtalksystems.com" target="_blank">dale.henrichs@gemtalksystems.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 12/09/2015 04:31 PM, Levente Uzonyi wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, 9 Dec 2015, Dale Henrichs wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On 12/09/2015 12:44 AM, Stephan Eggermont wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 08-12-15 22:35, Dale Henrichs wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What I meant is that you can't _always_ use the code point for<br>
collation, i.e., sorting based on the value of code points is not always<br>
correct[1].<br>
</blockquote>
<br>
I have given up on universal sorting when I learned that dutch libraries sorting of author names depends on the country of origin of the author. So if Jan van Beek is dutch he will be sorted under B, while if he's belgian under V. I haven't checked what happens if the author emigrates, or changes nationality...<br>
<br>
Stephan<br>
<br>
</blockquote>
Well, with ICU (and GemStone's implementation) you can choose which collator to use (Country specific) at the image level or on a comparison by comparison bases ... for example for an indexed collection (Unicode) Strings, you can choose the collator to use for that particular index ... so while it's true that universal sorter is not possible, it is possible to choose a collator that will satisfy a particlar customer ....<br>
</blockquote>
<br>
I expect my image to compare strings using the codepoint-based (+language tags) lexicographical method, because it's simple, deterministic and fast.<br>
Imagine having failing tests just because your image uses different default comparison methods based on some (external) parameter...<br>
It's also a nightmare to find out why your program is slow on some machine, while it's fast on another.<br>
</blockquote>
<br>
When we implemented the Unicode support in GemStone we preserved the legacy string classes and their legacy behavior ... We added new Unicode* classes with the new collator-based behavior for sorting and comparison ... That way legacy applications (and legacy) tests were not impacted by the choice of collator ... And folks could choose whether or not their application would benefit by the use of the new Unicode* classes....<br>
<br>
The ICU library performance is actually comparable to our original implementations, so there isn't a noticeable performance difference - we built the support into our vm and if folks are interested in some of the gory technical details, we'd be willing to share our experience, as there are several things that we did to minimize potential performance impacts ---<br></blockquote><div><br></div><div>Just so you know, I will dig my heels in as deeply as I am able to prevent the use of C++ libraries in the VM. It destroys the simulator, which is the most important thing we have for VM development productivity. As far as I'm concerned any use of external libraries to implement core functionality kills the VM-in-Smalltalk concept that Squeak (and Pharo) are built upon. So for me it's a non-starter. I hope others agree.</div><div></div></div><div class="gmail_extra"><br></div><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>