Re: [icu-design] proposal for Code Page detection for ICU4C

[Eric M. <em...@ic...>]

I think we should take care of the data loading behind the scenes. What 
we have to do to make things work shouldn't be the client's problem.

Regards,
Eric

Andy Heninger wrote:
> On 10/5/05, Badi Kumar S <ba...@ya...> wrote:
> 
>>I had a question about this API:
>>
>>ucsdet_getDetectableCharsetsCount(const UCharsetDetector *csd, UErrorCode *status);
>>
>>If we are implementing the Recognizers that the detector service uses,
>>as a static array of some sort, it would insure that this data would be
>>initialized before the library is loaded. Hence, I think we don't have
>>to force the user to supply a valid, open charset detector as the first
>>parameter to this function.
> 
> 
> I don't think that relying on static data will work out.  The data for
> charset detection will eventually move into the ICU data file
> (alongside charset conversion data, collation data, property data and
> everything else).   It would nice to force the loading to only happen
> on open() operations, and not as a side effect of other functions.
> 
> Another choice would be for getDetectableCharsetsCount() to force the
> data to load behind the scenes if it wasn't already loaded.  Checking
> (safely) whether a load is needed requires thread synchronization, but
> getDetectableCharsetsCount() probably isn't particularly performance
> sensitive, so the cost of mutexing it shouldn't be an issue.
> 
> 
>> I'm suggesting removing the first parameter.
> 
> 
> I'm not sure which way is best.  Requiring the parameter cleanly
> sidesteps all possible initialization problems.  On the other hand,
> the parameter is logically unnecessary, and it seems like
> implementation considerations may be having undue influence on the
> API.
> 
> Let's see what everyone else thinks.
> 
> -- Andy
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> icu-design mailing list
> icu...@li...
> To Un/Subscribe: https://lists.sourceforge.net/lists/listinfo/icu-design
> 
> 
>