Difference between revisions of "WEL and Unicode"
| Line 15: | Line 15: | ||
=The exceptions= | =The exceptions= | ||
In a few cases, STRING was used as an actual generic parameter. In this case it was also changed to STRING_32. However we cannot benefit from the conversion from STRING_32 to STRING. For those few cases, we have added an XXX_8 version of the XXX query so that the actual generic parameter is still STRING. It makes the transition easier as users only have to add the _8 to the end of the query they are using. | In a few cases, STRING was used as an actual generic parameter. In this case it was also changed to STRING_32. However we cannot benefit from the conversion from STRING_32 to STRING. For those few cases, we have added an XXX_8 version of the XXX query so that the actual generic parameter is still STRING. It makes the transition easier as users only have to add the _8 to the end of the query they are using. | ||
| + | |||
| + | If you find cases where this pattern was not applied, please contact us on the developer mailing list. | ||
Revision as of 12:34, 5 April 2006
Introduction
Starting with the 5.7.0826 release, WEL was switched from being ASCII based, to Unicode. The result is almost transparent to existing users modulo a few exceptions described below.
General Description
All WEL routines that used to have an argument of type STRING have been changed to STRING_GENERAL. STRING_GENERAL is a common ancestor to STRING and STRING_32 (the Unicode version of STRING).
All WEL queries whose return type was STRING, have been changed to a STRING_32 return type.
Why it works?
Although STRING_32 is not naturally convertible to a STRING, for the 5.7 release it will convert to STRING. Since currently everything is based on ASCII, it should not cause a problem. In 5.8, this conversion will be made obsolete and in 5.9 it will be gone. Giving some time to users to migrate their code.
The exceptions
In a few cases, STRING was used as an actual generic parameter. In this case it was also changed to STRING_32. However we cannot benefit from the conversion from STRING_32 to STRING. For those few cases, we have added an XXX_8 version of the XXX query so that the actual generic parameter is still STRING. It makes the transition easier as users only have to add the _8 to the end of the query they are using.
If you find cases where this pattern was not applied, please contact us on the developer mailing list.
