php-i18n Digest 2 Jun 2008 00:04:04 -0000 Issue 397
Topics (messages 1231 through 1233):
Re: intl 1.0.0RC1
1231 by: Stanislav Malyshev
1232 by: David Zülke
1233 by: Darren Cook
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
--- Begin Message ---
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]
--- End Message ---
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
> - 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
I'd like to second this proposal. Consistency and
far-less-likely-to-clash-with-existing-code are more important (IMHO)
than slightly longer, slightly uglier names. It also makes it easier to
identify which code is coming from which library (*).
Namespaces were supposed to be in php5 but got pulled at the last minute
(IIRC), but I see they will be in php6. Perhaps the Intl prefix could be
used consistently on the php5 version, and not used at all (i.e.
IntlDateFormatter becomes DateFormatter) in php6? On the other hand,
having to rename functions to move from php5 to php6 would be unpopular?
Are any other php6 libraries planning to drop prefixes?
Darren
*: This is why I often use full names in C++, such as std::cout, instead
of "using namespace std;"
--
Darren Cook, Software Developer/Researcher
http://dcook.org/mlsn/ (English-Japanese-German-Chinese-Arabic
open source dictionary/semantic network)
http://dcook.org/work/ (About me and my work)
http://dcook.org/work/charts/ (My flash charting demos)
--- End Message ---
