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]
--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
