To follow up, I downloaded a more recent Pharo and analyzed senders of #unicodeToMacRoman Most are in FreeType but one in unused message TTFontReader>>#winToMac: FreeType mostly use this pattern: aCharacter unicodeToMacRoman asUnicode asInteger except: FreeTypeFont>>#linearKerningLeft:right: -> which further calls FT2Face>>#kerningLeft:right: -> -> which further apply (self primGetCharIndex: leftCharacter asInteger) So the two patterns I see for #unicodeToMacRoman usage are: aCharacter unicodeToMacRoman asUnicode asInteger and for Kerning: aCharacter unicodeToMacRoman asInteger Note that (asUnicode asInteger) seems to be a workaround for kind of old bug/mess like http://bugs.squeak.org/view.php?id=6395 The other message #macRomanToUnicode has a single sender TTFontreader>>#macToWin: which uses the pattern i announced macRomanCharCode asCharacter macRomanToUnicode charCode So, as announced, I conclude there is no use in forming a Character when we only need a charCode in a specific encoding... QED Nicolas 2009/4/1 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
Hello list,
that's just a detail, but I do not much like Character>>unicodeToMacRoman.
Why? Because a Character does not explicitely carry encoding information. On the contrary, Character are implicitely considered as unicode encoded in 99% of code.
So, pretending a Character can change encoding is just a hack for a small portion of code... ...and IMO a ugly one because a Debugger for example would be fooled and its user too (ego quoque). I bet most usages of this message will be (someCharacter unicodeToMacRoman charCode), so the pretended MacRoman encoded Character does not really need to exist... (Shame on me, I have not downloaded a recent image, I'm just picking changes here and there).
If what I say is true, wouldn't a Character>>macRomanCharCode be more clean?
Nicolas