Difference between revisions of "WEL and Unicode"
Peter gummer (Talk | contribs) m (→Why it works?) |
|||
| (3 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
[[Category:WEL]] | [[Category:WEL]] | ||
| − | [[Category: | + | [[Category:Unicode]] |
=Introduction= | =Introduction= | ||
| Line 10: | Line 10: | ||
All WEL queries whose return type was STRING, have been changed to a STRING_32 return type. | All WEL queries whose return type was STRING, have been changed to a STRING_32 return type. | ||
| − | =Why it | + | =Why does it work?= |
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. | 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= | =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. | ||
Latest revision as of 05:36, 18 September 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 does it work?
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.
