Re: [PHP-I18N] intl 1.0.0RC1

[email protected] (Stanislav Malyshev) Wed, 04 Jun 2008 15:44:22 +0300
Newsgroups php.i18n
Organization Zend Technologies
Message-ID <[email protected]>
Hi!

> Obviously, it is less likely that someone who wrote a Collator called 
> their class "IntlCollator" instead of "Collator".

But we want to use Collator name, because we want to use these classes 
in PHP 6, and we want PHP collation be called Collator, just as PHP date 
functions are called DateTime and PHP's COM handling class is called 
COM, even though somebody could have their own implementation of COM and 
date/time handling.

> complain about. This should really be changed to be consistent across 
> the board, Stas.

I don't see why adding unnecessary prefixes to function names would add 
anything. When you want to do collation, you expect your class to be 
named "collator", and when you want to deal with locales, you want the 
class to be named "locale". What's "inconsistent" in that - that they 
start from different letters?

> I mean who are you/we to decide that someone from the Republic of 
> Serbia, who speaks Serbian, may not view sales numbers for last week's 
> month in the thai-buddhist calendar in USD and sorted "traditionally"?

I don't decide anything on which locales people use. Though people that 
actually work in the i18n field says using such locales are extremely 
rare, and I believe them.
But in any case, you don't need yo use calendar for collator, and you 
don't need to use currency for date/time formatting.

>> Please tell that to the ICU library developers. 98-byte long locale
>> provably crashes ICU libraries. I didn't want to take chances so I chose
>> smallest "round" number for the limit that works reliably. I'd be 
>> happy to raise it if I could be sure ICU would work OK with it.
> 
> 97? ;)

I can't be really sure any other ICU function wouldn't crash on any 
other OS on 97. I could raise it, but how 97 is that better than 64? If 
you suppose people stuff everything and a kitchen sink there, 97 could 
be as easily overrun. If you base on most frequent usage, 64 is more 
than enough. If there's a case to be made for making it not 64 but any 
other number, I'm ready to hear it - but I want some real-life data on it.

> But you have to parse the locale string each time, right? That is 

No, I don't. ICU API takes char*.
-- 
Stanislav Malyshev, Zend Software Architect
[email protected]   http://www.zend.com/
(408)253-8829   MSN: [email protected]