WEL and Unicode - Revision history

Peter gummer: /* Why it works? */

2006-09-18T14:36:24Z

Why it works?

← Older revision		Revision as of 14:36, 18 September 2006
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 ~~works~~?=		=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.

Manus at 21:34, 5 April 2006

2006-04-05T21:34:39Z

← Older revision		Revision as of 21:34, 5 April 2006
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.

Manus at 21:32, 5 April 2006

2006-04-05T21:32:01Z

← Older revision		Revision as of 21:32, 5 April 2006
Line 1:		Line 1:
	[[Category:WEL]]		[[Category:WEL]]
	[[Category:~~UNICODE~~]]		[[Category:Unicode]]

	=Introduction=		=Introduction=

Manus: WEL and UNICODE moved to WEL and Unicode

2006-04-05T21:31:01Z

WEL and UNICODE moved to WEL and Unicode

← Older revision	Revision as of 21:31, 5 April 2006
(No difference)

Manus at 21:29, 5 April 2006

2006-04-05T21:29:57Z

← Older revision		Revision as of 21:29, 5 April 2006
Line 1:		Line 1:
	[[Category:WEL]]		[[Category:WEL]]
			[[Category:UNICODE]]

	=Introduction=		=Introduction=

Manus: Description about WEL was made Unicode.

2006-04-05T21:27:52Z

Description about WEL was made Unicode.

New page

[[Category:WEL]]

=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.