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.
- 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.
- 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.
- 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.
- 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.
- http://php.net/manual/en/intl.examples.php uses a "getLocaleByType()"
method that does not exist
Thanks. should be just getLocale().
--
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
