WEL and Unicode - Revision history

Peter gummer: /* Why it works? */

2006-09-18T14:36:24Z

‎Why it works?

Manus at 21:34, 5 April 2006

2006-04-05T21:34:39Z

Manus at 21:32, 5 April 2006

2006-04-05T21:32:01Z

Manus: WEL and UNICODE moved to WEL and Unicode

2006-04-05T21:31:01Z

WEL and UNICODE moved to WEL and Unicode

Manus at 21:29, 5 April 2006

2006-04-05T21:29:57Z

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.

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

@@ Line 1: / Line 1: @@
 [[Category:WEL]]
-[[Category:UNICODE]]
+[[Category:Unicode]]
 =Introduction=

← Older revision		Revision as of 21:29, 5 April 2006
Line 1:		Line 1:
	[[Category:WEL]]		[[Category:WEL]]
		+	[[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.
-=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.

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