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>.'''
+
# 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>.'''
+
# 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>FILE_NAME_32</e>
+
| <e>PATH</e>
 
|-
 
|-
 
| <e>DIRECTORY_NAME</e>
 
| <e>DIRECTORY_NAME</e>
−
| <e>DIRECTORY_NAME_32</e>
+
| <e>PATH</e>
−
|-
+
−
| <e>FILE</e>
+
−
| <e>FILE_32</e>
+
−
|-
+
−
| <e>RAW_FILE</e>
+
−
| <e>RAW_FILE_32</e>
+
−
|-
+
−
| <e>PLAIN_TEXT_FILE</e>
+
−
| <e>PLAIN_TEXT_FILE_32</e>
+
−
|-
+
−
| <e>DIRECTORY</e>
+
−
| <e>DIRECTORY_32</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>.
−
# If you want to operate on files with an unknown string type for their names (i.e. <e>READABLE_STRING_GENERAL</e>), use <e>FILE_UTILITIES</e>. This is an expanded class and can be used as described for <e>UTF_CONVERTER</e>.
 

Revision as of 16:07, 8 November 2012


This is a summary of the recommendations for adapting applications to handle Unicode.

General rule

  1. 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 using STRING_8 or its variant. Always use IMMUTABLE_STRING_32, READABLE_STRING_32 or STRING_32.
  2. Do not use classes from third-party libraries that take STRING_8 rather than STRING_32.
  3. Use PATH to manipulate file or directory names
  4. 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

  1. 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
  1. Consider using READABLE_STRING_32 for argument types. If you cannot immediately change argument types to take READABLE_STRING_32, e.g. because this is a library class, use READABLE_STRING_GENERAL and perform all the necessary conversions inside the routine.
  2. 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.
  3. Consider using SHARED_EXECUTION_ENVIRONMENT to access EXECUTION_ENVIRONMENT_32.
Retrieved from "https://dev.eiffel.com/index.php?title=Migration_to_Unicode&oldid=14616"