[Glass] [3.4.0] Strange behaviour with indices ...

[Johan Brichau via Glass]

Hi,

Skimming this thread… we uncovered that problem as well in our migration from GS2.4 to GS 3.2 (or later). 
We started seeing strange differences and only recently unlocked the issue:

Even when using the locale en_US_POSIX, there seem to be cases where Strings are not compared by comparing their integer code point values. Example Strings:
string1 := String with: (Character codePoint: 16r00E9).
string2 := String with: (Character codePoint: 16r0065) with: (Character codePoint: 16r0301).

Even with the default IcuLocale set to en_US_POSIX, these strings are #=-equal:
string1 = string2 "=> true"
While this is not GemStone2-compatible behavior, it's not that bad for the Strings to be equal according to #=, as they are in fact canonically equivalent. However, the Strings do not have the same #hash:
string1 hash = string2 hash "=> false”

I’m primarily concerned with places we are using dictionaries with strings as keys and when we are upgrading from GS2.4 to GS3.2 (or later).

Cheers,
Johan

> On 20 Mar 2018, at 10:17, monty via Glass <glass at lists.gemtalksystems.com> wrote:
> 
> Dale, you're busy, but did you read the whole String>>#= thread? This:
> | one two |
> one := 'Köln'.
> two :=  String with: $K with: $o with: 16r308 asCharacter with: $l with: $n.
> one = two
> 	and: [one hash ~= two hash]
> 
> is absolutely a bug, not just a surprise. To be consistent with #=, String>>#hash must normalize (with UCI) its string before computing its hash.
> 
> (IMO #=, #<=, etc doing implicit normalization before comparing was a mistake. Either the Java/C# way of making the user manually normalize the strings before comparing or the Perl6 way of storing strings internally in a pre-normalized form would have been more intuitive and consistent. I assume it's too late to change now.)
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass