Grease support for difference between platform's unicode support

[jbrichau]

VAST has Unicode support using UnicodeString and Grapheme classes.
Pharo and GemStone have Unicode support built-in String.

Porting Seaside to VAST requires changes to the base code of Seaside instead of to platform-specific packages. Therefore moving this difference to Grease would be beneficial.

An example is WAJSONParser>>parseCharacterHex.

To be detailed further... this issue serves as the placeholder.

[marschall]

We send #codePoint: to Character in various other places as well:

• WATableBasedEncoder class >> #maximumCharacterValue
• WAUrlEncoder class >> #initializeTable
• WAUrl class #decodePercent:, #decodePercent:from:to, #decodePercentAndPlus:from:to

[jbrichau]

A first thought here was to introduce some abstractions for Unicode concepts in Grease but I think that trying to bridge the difference between the Unicode abstractions in VAST and the Unicode strings in the other platforms is going to complicate things too much. Iterating over a String is already different (i.e. iterating over Grapheme in VAST and iterating over (essentially) scalars (though Character is used) in Pharo and GemStone).

We will therefore just focus on code changes that provide the ability to the VAST platform port to specialize things where necessary. One thing we would like to add to Grease for that is a method GRPlatform>>#stringFromUnicodeCodepoints:. This will allow test cases code (mostly) to create a String from codepoints and in VAST this can easily return a UnicodeString rather than a String. It will allow to abstract away from the fact that Character>>codePoint: is limited in VAST.

So, to avoid usingCharacter>>codePoint: in VAST where really either a UnicodeScalar should be created, or where a Grapheme should be created, we propose the framework is adapted such that the code can be overridden rather than creating a Grease method for it.

This would mean:

• WAJsonParser should be constructed via GRPlatform, similar to how WAUrlEncoder, WAJsonEncoder and WAXmlEncoder are created. This will allow VAST to specialize the implementation and create the strings accordingly.
• WATableBasedEncoder should not be changed since the Character class reference is in the superclass and all (concrete) subclasses are the ones mentioned above
• WAUrl's percent-decoding actually works because the percent encoding values are always in the single byte range. In VAST, a decoded URL is treated again by the adaptor to combine the decoded bytes into a UnicodeString if the codec is set to support Unicode. This should be cleaned in the future perhaps, but it currently does not need be changed.