Am 01.06.2008 um 07:43 schrieb Stanislav Malyshev:
Hi!
- I still think IntlDateFormatter vs the rest w/o Intl prefix is
inconsistent. Can't we just prefix it with "Intl" across the board?
Saves trouble down the road
Because frankly this prefix sucks and so do names like
IntlMessageFormatter. In order to avoid conflict with Date extension
I had to rename the date formatter, but I really don't want to make
it uglier than it must be.
What if there is a Number extension down the road. Or a Collator
extension. Or what if people already have classes called
NumberFormatter etc. That's not too unlikely. I agree that those
prefixes are ugly, but I firmly believe that it is more important to
have consistency across the board. "Intl" prefix for all classes just
makes more sense.
- DateFormatter::parse() and DateFormater::localtime() should have
the second argument ($parse_pos) as a reference - it is supposed to
"return" the position where an error occured, in case it could not
parse the given value. ICU does have it this way, and I think PHP
should, too.
Please add it as feature request bug report.
Okay.
- IntlDateFormatter::format() does not accept DateTime (I think
that is a known issue)
- There is no way to use or retrieve milliseconds, so far
And these too. First of these is planned as for the second one it
depends on if ICU allows that.
I believe it does, yeah.
- What does Collator::sortWithKeys() do, exactly? Why not always
have this one? Why does the API have a "normal" sorting function
and an optimized one? Why not just always use the sorting with
ucol_getSortKey() keys? And why is there no
Collator::asortWithKeys(), to keep the API consistent?
sortWithKeys generates collation keys for each entry prior to
sorting, which is supposed to speed it up. But it depends on how
many entries there are - it may prove not efficient to store all
those keys.
But why are those internal differences exposed through the API. I
think that is bad design. I as a caller should not have to bother
thinking about the internal implementation of the two methods and then
decide which to use. That's why I'm using the extension, after all, to
have things convenient.
At least, there should be Collator::asortWithKeys(). But I really
believe that both sort() and asort() should use the variant with
generated collation keys, if that one becomes faster as the array size
grows.
You're saying "it may not prove efficient"... did you or anyone
benchmark it? ;) Having two methods with the same behavior, just
different implementations due to a gut feeling might not be the best
idea. I'm failing to get the extension compiled here on OS X, but will
go ahead and do benchmarks ASAP
- INTL_MAX_LOCALE_LEN is 64 - what if I have a longer locale
string, with options?
Well, do you? We can increase it, but we have to have some limit
since ICU can't stomach overlong locales.
Absolutely...
[EMAIL PROTECTED];collation=traditional;calendar=thai-
buddhist is what I could come up with right now... 77 characters.
The other question is what happens if the string is longer than that?
Does it get cut off or something?
Assume this:
sr_Latn_RS_REVISED
@currency=USD;collation=traditional;mykeyword=myvalue;calendar=thai-
buddhist
That is, in theory, legal. "mykeyword" would be parsed by my custom
message formatter implementation that can localize... ancient maya
wall paintings. Or whatever. So locale identifier strings can be of
any length.
Maybe ext/intl should do this:
- Accept locale strings of arbitrarys length
- Parse them and throw out any keywords ICU cannot handle (i.e.
everything except "collation", "currency" and "calendar", AFAIK)
- Hand the resulting string over to ICU
What confuses me, in general, is why locales are not implemented as
objects. Why do I have to pass a locale string to every locale-aware
function?
Also... having uloc_acceptLanguageFromHTTP exposed in the API would be
pretty neat ;) Since apparently, that does a mapping of e.g. "en-GB"
to "en_UK" etc
And.. is there going to be Resources support in the future? AFAIK, the
CLDR data is compiled to ICU resource bundles, right? That would allow
reading and using the CLDR data of a locale. Like... reading localized
country and language names. Yummy. We currently have all this stuff
implemented in userland PHP code, which is, er, a bit slow :)
Cheers,
David
--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
