Re: [PHP-I18N] intl 1.0.0RC1

Hi Stas,

some things we noticed:

- 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

- 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. It's pretty valuable information, and if only for  
debugging purposes.
- IntlDateFormatter::format() does not accept DateTime (I think that  
is a known issue)
- There is no way to use or retrieve milliseconds, so far

- 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?

- INTL_MAX_LOCALE_LEN is 64 - what if I have a longer locale string,  
with options?

- http://php.net/manual/en/intl.examples.php uses a  
"getLocaleByType()" method that does not exist

The only "critical" thing, I would say, is having the $parse_pos  
argument as a reference, as changing that in a later release would  
break code if people pass a value directly. The rest is pretty much  
just questions I'm hoping you could answer, not actual problems ;)

Cheers,

David


Am 27.05.2008 um 23:26 schrieb Stanislav Malyshev:

> Hi!
>
> I've uploaded 1.0.0RC1 version of intl extension on PECL. Please  
> test it and if you think anything has to be added/fixed for 1.0.0  
> please tell.
> -- 
> 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
>
>