Re: ICU4C Proposal: Add missing uset.h functions

In response to the feedback, I'm modifying my proposal as follows.  Thank 
you for the comments.

1) There was a typo for the uset_charAt return type.  It is suppose to be 
UChar32, and not int32_t.
2) Remove proposal for uset_addMatchSetTo
3) Remove the USet argument for uset_resemblesPattern
4) Add the compact API.  Barry had this in his original proposal, and I 
mistakenly missed it.

The closerOver C++ API is not duplicated in this C API because it is still 
@internal.  If someone else wants to finish this C++ API and propose it as 
non-internal, then we can have a mirrored C API too.

The other APIs can be considered for a future proposal in the 3.2 
timeframe.  I guess this will be proposal part 1.

George Rhoten
IBM Globalization Center of Competency/ICU  San José, CA, USA
ICU main website: http://oss.software.ibm.com/icu/index.html



Andy Heninger <[email protected]> 
Sent by: [email protected]
08/10/2004 02:35 PM
Please respond to
andyh


To
[email protected]
cc
[email protected]
Subject
Re: ICU4C Proposal: Add missing uset.h functions






George Rhoten wrote:
> There are some C++ UnicodeSet functions that are missing from the uset_* 
C 
> API.  I propose that some missing functions be added.  This proposal is 
> for jitterbug 3341.

This will be really good to have.

A couple of comments -

 > /**
 >  * Implementation of UnicodeMatcher API.  Union the set of all
 >  * characters that may be matched by this object into the given
 >  * set.
 >  * @param set the source used to generate the union
 >  * @param toUnionTo the set into which to union the source characters
 >  * @draft ICU 3.2
 >  */
 > U_DRAFT void U_EXPORT2
 > uset_addMatchSetTo(const USet* set, USet* toUnionTo);

I don't think that we need this function.  It does the same thing as the 
already existing uset_addAll(), and exists as a separate function in the 
  C++ UnicodeSet class only because that class is implementing the 
UnicodeMatcher interface.

The class hierarchy was probably a mistake - it ties UnicodeSet too much 
to transliterators, while UnicodeSet is a more general concept.  At any 
rate, there's no need to propagate this into the C API.

-------

 > /**
 >  * Return true if the given position, in the given pattern, appears
 >  * to be the start of a UnicodeSet pattern.
 >  *
 >  * @param set the object to be tested for the given pattern and 
position
 >  * @param pattern a string specifying the pattern
 >  * @param patternLength the length of the pattern, or -1 if NULL
 >  * @param pos the given position
 >  * @draft ICU 3.2
 >  */
 > U_DRAFT UBool U_EXPORT2
 > uset_resemblesPattern(const USet* set,
 >                       const UChar *pattern, int32_t patternLength,
 >                       int32_t pos);

The first parameter, "set" shouldn't be there.  (In C++, it's a static 
function).

I'm not so sure that the function should have been included at all, but 
I guess since it's there in C++ that we should include it in the the C 
side for completeness.  All it does is check whether the first character 
being pointed to is a '['.

----

The following functions are available in the C++ UnicodeSet class, but 
not from C  (including the new proposal)

                 clone()
                 hashCode()               <--  Good to have
                 ContainsAll(), ContainsNone(), ContainsSome()  variants 
that
             take  check against a range or a string.
             (The functions checking a against a USet are present)
                 addAll(string s);
                 retainAll(String s);
                 complementAll(String);
                 complement(Range)
                 complement(string);
                 removeAll(String);
                 createFrom(String);
                 createFromAll(String);
                 closeOver(attribute)       <-- important for case folding
         compact()                  <--  Good to have

                 getRangeCount()            <-- I'd prefer not to include 
these.
         getRangeStart()            <--  They expose too much
         getRangeEnd()              <--   implementation.


If the goal is to reproduce the C++ UnicodeSet functionality in the C 
API, probably at least some of these functions should be added as well.

Omitting overloaded functions that take a UChar32 code point parameter 
when a variant that takes a range already exists seems reasonable - the 
impact on user code is very small.

Omitting variants that take ranges or strings has a bigger impact.  The 
work around involves either loops or temporary objects in the client 
code.  But I'm not sure whether they are used much.

-- 
   -- Andy Heninger
      [email protected]

_______________________________________________
icu mailing list
[email protected]
http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu