Eliot Miranda wrote:
> I agree, and hence why not:
> 
>        [#[ 16r74 "t" 16r72 "r" 16r75 "u" 16r65 "e" ] -> ["Version 1.0 
> TTF file"
>               
>  "http://developer.apple.com/textfonts/TTRefMan/RM06/Chap6.html
>                The values 'true' (16r74727565 in ascii) and 16r00010000 
> are recognized by the Mac OS
>                as referring to TrueType fonts."
>                ^Array with: 0 "only one font"
>        ].
> 
> ?  Use of 16r is to be preferred to 0x because this is a comment to be 
> read by Smalltalk programmers.

Using #[ 16r74 "t" 16r72 "r" 16r75 "u" 16r65 "e" ] is even worse than 
the alternatives because now you can't even see if what you wrote is 
what's expected to be there. Shudder. You *really* want to read and 
debug code that looks like that? I most definitely don't.

Regarding the "oh, this would be a problem if the string encoding 
changes", let's keep in mind that the string encoding *hasn't* changed 
for ASCII. So, no, it's specifically incorrect to say that the past 
change would have affected or invalidated that code. I don't think you 
understand how fundamental the impact of an encoding change is - if you 
did that *all* string literals would look like gobbly gook. The only 
reason we could do it for non-ascii was that we're not using any 
non-ascii characters and we were only switching the characters > 127 
from Mac Roman to Unicode/Latin-1. If you don't believe me, grab your 
favorite non-ascii piece of text and throw it at "yourText squeakToMac" 
and have a look at it.

So the argument that the dependency on literal string encoding is an 
issue is bogus. If you change literal string encoding there are so many 
other places that break it's not even funny. And at least I don't design 
for the implausible (what reason do we have to expect the encoding to 
change in the next fifty years?)

Cheers,
   - Andreas