It would be nice to clean that situation in 1.3 I think that we should get some tasks and tackle it together. Probably more pair programming would help. Stef On Jul 29, 2010, at 10:42 AM, Henrik Johansen wrote:
On Jul 29, 2010, at 9:23 54AM, Philippe Marschall wrote:
On 07/28/2010 10:48 PM, Alexandre Bergel wrote:
I'd even suggest the system to reject names and selectors not in ASCII.
I agree for what has to be put in PharoCore and Pharo. However, a user lambda must be able to create a class called MaClassePréférée if he/she wishes. Every beginner do this...
Are you sure all your subsystems (changesets, fileouts, changes file, Monticello, ...) are Unicode aware? Do you use Unicode normalization? If so which one?
Cheers Philippe
+1. Venture outside the ascii-range, and you are asking for trouble when storing code externally. AFAIK, only the .sources / .changes *supposedly* uses utf8 natively. Heck, MultiByteFileStream>>setConverterForCode uses MacRoman unless you've written the utf8 BOM-marker ... Use MultiByteBinaryOrTextStream>>setEncoderForSourceCodeNamed: , and it WILL use MacRoman for .cs or .st files no matter what the streams contents are (thankfully, there are no senders in the core image, at least) Which is weird to me, since ByteString encoding is assumed to be 8859-1, and the default fonts displays 8859-15 characters :) Change any of this however, and you will surely break some old filed-out code.
TLDR; There is no overall strategy for ensuring that code will be saved externally in a unicode-compatible encoding, and it's probably impossible to implement one while maintaining backwards-compatability. If you want to stay safe, use only ASCII. If you plan to never export any code (say, use changesets or Monticello), write in whatever language you want. (well, as long as you are able to input the characters of course)
Cheers, Henry _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project