Re: [PHP-I18N] intl 1.0.0RC1

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...  
sr_Latn_RS_REVISED@currency=USD;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