Difference between revisions of "Migration to Unicode"
m (→Temporary solution: Splitted item #4.) |
(Updated rules for Unicode migration to the latest EiffelBase design) |
||
Line 4: | Line 4: | ||
====General rule==== | ====General rule==== | ||
− | # | + | # Never use <e>STRING_8</e> or 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 using <e>STRING_8</e> or its variant. Always use <e>IMMUTABLE_STRING_32</e>, <e>READABLE_STRING_32</e> or <e>STRING_32</e>. |
− | # | + | # Do not use classes from third-party libraries that take <e>STRING_8</e> rather than <e>STRING_32</e>. |
+ | # Use <e>PATH</e> to 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==== | ====Temporary solution==== | ||
Line 20: | Line 22: | ||
|- | |- | ||
| <e>FILE_NAME</e> | | <e>FILE_NAME</e> | ||
− | | <e> | + | | <e>PATH</e> |
|- | |- | ||
| <e>DIRECTORY_NAME</e> | | <e>DIRECTORY_NAME</e> | ||
− | | <e> | + | | <e>PATH</e> |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
|- | |- | ||
| <e>KL_BINARY_INPUT_FILE</e> | | <e>KL_BINARY_INPUT_FILE</e> | ||
Line 49: | Line 39: | ||
# If you need to convert one UTF encoding into another one, use <e>UTF_CONVERTER</e>. 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. | # If you need to convert one UTF encoding into another one, use <e>UTF_CONVERTER</e>. 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 <e>SHARED_EXECUTION_ENVIRONMENT</e> to access <e>EXECUTION_ENVIRONMENT_32</e>. | # Consider using <e>SHARED_EXECUTION_ENVIRONMENT</e> to access <e>EXECUTION_ENVIRONMENT_32</e>. | ||
− |
Revision as of 16:07, 8 November 2012
This is a summary of the recommendations for adapting applications to handle Unicode.
General rule
- Never use
STRING_8
or 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_8
or its variant. Always useIMMUTABLE_STRING_32
,READABLE_STRING_32
orSTRING_32
. - Do not use classes from third-party libraries that take
STRING_8
rather thanSTRING_32
. - Use
PATH
to 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_32
for argument types. If you cannot immediately change argument types to takeREADABLE_STRING_32
, e.g. because this is a library class, useREADABLE_STRING_GENERAL
and 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_ENVIRONMENT
to accessEXECUTION_ENVIRONMENT_32
.