Am 04.06.2008 um 14:44 schrieb Stanislav Malyshev:
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.
Then do the right thing and make it PHP 5.3+ and namespace it right
from the beginning.
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?
The inconsistency is that one class, IntlDateFormatter, has a prefix.
And the others do not.
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.
That is correct.
However, that means I would need to parse a locale string, extract
only the information I need for a particular task, and pass a new
locale string containing only the relevant information.
This cannot be the point of this extension, Stas. It must make my life
easier, not more complicated.
Like with the sort() method, it is completely wrong to expose
implementational details through the API. And that's what this is doing.
We've ported several parts of ICU to PHP code. We know the problems
and the situations that arise. We have quite some experience in
building and designing a proper API. Please trust me here.
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.
I gave you the Chinese example already. 65 chars. And this _will_
occur in the wild, believe me. The fun thing about i18n is that the
strangest things you couldn't possibly imagine can occur.
But you have to parse the locale string each time, right? That is
No, I don't. ICU API takes char*.
Right. IIRC, they accept objects, too. The NumberFormatter accepts
only locale objects AFAIK.
Cheerio,
David
--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
