User:Waldo/Internationalization API: Difference between revisions

m
Clarify ICU API stability
(Talk some about number formatting)
m (Clarify ICU API stability)
Line 59: Line 59:
ICU's source code is relatively huge and sprawling: hardly surprising for a 15+ year old project.  {{source|intl/icu/source/common/unicode/}} is probably the most interesting directory, from SpiderMonkey's point of view, as it contains the public headers and interfaces used by SpiderMonkey.  Each header and interface within contains copious documentation of the behavior of the function/enum/etc. in question.  The documentation isn't always perfectly clear, but quite often it's enough to know how to use the functionality without having to read the implementation.
ICU's source code is relatively huge and sprawling: hardly surprising for a 15+ year old project.  {{source|intl/icu/source/common/unicode/}} is probably the most interesting directory, from SpiderMonkey's point of view, as it contains the public headers and interfaces used by SpiderMonkey.  Each header and interface within contains copious documentation of the behavior of the function/enum/etc. in question.  The documentation isn't always perfectly clear, but quite often it's enough to know how to use the functionality without having to read the implementation.


ICU provides both C and C++ APIs, but only the C API is considered stable.  Given that some people reasonably want to use SpiderMonkey with a system ICU, this means we're generally limited to only the stable C API.  (In one case we have to use the C++ API to access functionality; see known issues below.)  Unfortunately, this also means we have to hand-roll our own smart pointer for managing ICU resources.
ICU provides both C and C++ APIs, but the only stable interfaces are C APIs marked as stable.  (C++ APIs are considered uniformly unstable.  This extends even to interfaces defined entirely in public ICU headers, such as ICU smart pointers.) Given that some people reasonably want to use SpiderMonkey with a system ICU, this means we're generally limited to only the stable C API.  (In one case we have to use the C++ API to access functionality; see known issues below.)  Unfortunately, this also means we have to hand-roll our own smart pointer for managing ICU resources.


Most of the ICU methods indicate errors through an error code outparam.  Also, such APIs check the existing value in that outparam before proceeding.  Thus a sequence of ICU calls can occur without error-checking right up til the end, where a single <code>U_FAILURE(status)</code> will suffice to handle all errors that might occur.  For example:
Most of the ICU methods indicate errors through an error code outparam.  Also, such APIs check the existing value in that outparam before proceeding.  Thus a sequence of ICU calls can occur without error-checking right up til the end, where a single <code>U_FAILURE(status)</code> will suffice to handle all errors that might occur.  For example:
Confirmed users
446

edits