Migration to Unicode
Revision as of 15:07, 8 November 2012 by Manus  (Talk | contribs) (Updated rules for Unicode migration to the latest EiffelBase design)
This is a summary of the recommendations for adapting applications to handle Unicode.
General rule
-  Never use 
STRING_8or any variant of it unless you write a program that is going to be deleted in 5 minutes after running it. Do not even consider usingSTRING_8or its variant. Always useIMMUTABLE_STRING_32,READABLE_STRING_32orSTRING_32. -  Do not use classes from third-party libraries that take 
STRING_8rather thanSTRING_32. -  Use 
PATHto manipulate file or directory names - Whenever an API takes a READABLE_STRING_GENERAL argument, assumes that STRING_8 will be treated as Unicode strings in the range 0 .. 255, unless explicitly noted.
 
Temporary solution
- Replace types using the following table:
 
| Old class | New class | 
|---|---|
 STRING_8
 | 
 STRING_32
 | 
 FILE_NAME
 | 
 PATH
 | 
 DIRECTORY_NAME
 | 
 PATH
 | 
 KL_BINARY_INPUT_FILE
 | 
 KL_BINARY_INPUT_FILE_32
 | 
 KL_TEXT_OUTPUT_FILE
 | 
 KL_TEXT_OUTPUT_FILE_32
 | 
 EXECUTION_ENVIRONMENT
 | 
 EXECUTION_ENVIRONMENT_32
 | 
-  Consider using 
READABLE_STRING_32for argument types. If you cannot immediately change argument types to takeREADABLE_STRING_32, e.g. because this is a library class, useREADABLE_STRING_GENERALand perform all the necessary conversions inside the routine. -  If you need to convert one UTF encoding into another one, use 
UTF_CONVERTER. This is an expanded class, so it's possible to declare a local variable of this type and call features on it without explicit object creation. -  Consider using 
SHARED_EXECUTION_ENVIRONMENTto accessEXECUTION_ENVIRONMENT_32. 

