Proposal to deprecate class CollationKey and its related APIs
syn wee <[email protected]>
| Newsgroups | gmane.comp.lib.icu.general |
|---|---|
| Message-ID | <[email protected]> |
Proposal to deprecate class CollationKey and its related APIs in ICU4C
Please respond with comments by Oct 6 2003
This is a proposal to deprecate:
1) The class CollationKey and all its API
2) The 2 getCollationKey methods in class Collator
virtual CollationKey& getCollationKey(const UnicodeString& source,
CollationKey& key,
UErrorCode& status) const = 0;
and
virtual CollationKey& getCollationKey(const UChar*source,
int32_t sourceLength,
CollationKey& key,
UErrorCode& status) const = 0;
3) The 2 getCollationKey methods, similar to the ones in 2), in class
RuleBasedCollator
These APIs will be deprecated and no new APIs will be added to support
CollationKey. There are no intentions to remove them yet. Users are
highly encouraged to use unsigned byte arrays for storage of sort order
instead of CollationKeys. Please refer to ucol.h for APIs to use with
the unsigned byte arrays.
ICU4C files affected: coll.h, tblcoll.h and sortkey.h
Reasons for deprecation:
1) The class CollationKey in ICU4C has been around since 1999, it was
designed to synch with the JDK version of java.text.CollationKey. It is
only an extra layer of wrapper around a unsigned byte array representing
a sort order and provides very simple APIs to access the array.
2) The underlying Collation engine in ICU4C has been internally
manipulating unsigned byte arrays directly for sometime. All collation
functionality are optimized for use with the unsigned byte arrays and
not CollationKeys. Unsigned byte arrays are strongly encouraged instead
of CollationKeys.
3) A full set of APIs has been provided to manipulate sort orders via
its unsigned byte array representations, same similar APIs do not exists
for manipulating CollationKey objects. Examples of APIs that supports
only unsigned byte arrays
* ucol_nextSortKeyPart
* ucol_mergeSortkeys
* ucol_getBound etc...
Regards,
Syn Wee.