Hi Stan, Andi and al!
On Fri, Apr 4, 2008 at 11:59 PM, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> > -----Original Message-----
> > From: Pierre Joye [mailto:[EMAIL PROTECTED]
> > Sent: Friday, April 04, 2008 12:33 PM
> > To: Stas Malyshev
> > Cc: Lester Caine; PHP internals
>
> > Subject: Re: [PHP-DEV] intl naming
> >
> >
> > It is also amazing to systematically ignore my comments about your off
> > list discussions (same in Andi's reply).
> >
>
> Actually I didn't. Go and read my answer from April 1st.
does that count? =)
More seriously, it does not matter if you were in favor of this
private list or not, you should have refused it. But that's my
personal opinion and I agree with you, point made.
Now about ICU, I like its simplicity. There is a clear attempt to keep
the API readable and understable by the common users. Thanks for that!
I run some tests today based on my initial thoughts (which were based
only on the documentations). I even tried with a small application
here. I try to stay as constructive as possible in my comments,
suggestions or remarks. However, I know that my English or my tone may
give the impression that I try to impose my choice, that's not the
case :) please try to keep that in mind while reading.
I also apologize for the long text, I tried to keep it concise (and failed).
The numbering is only about helping possible replies or discussions.
They do not reflect any kind of priority or preferences.
1. Procedural API is somehow useless. It duplicates the complete API
without adding any gain.
2. Multiple ways to create intl instances, I'm not sure we need both
the factory and the constructor. It does not help the user to achieve
his goal but create more possible confusions (and cause of errors/
bugs). What was the idea behind ::create (if "new" has to be
supported)
3. too many repetitive arguements, especially the locale.
The ICU API solves this issue nicely using the current locale. It
would be easier to work with the intl API if the same principle was
used. Add a Locale::setDefault() and Locale::getDefault().
The argument order for the constructors/factories should be change to
allow that. The locale argument has to be optional (and moved as 2nd+
argument).
Arguments order may be confusing and hard to remember. However their
names are self explaining as long as one is familiar with the ICU
terminology. It would rock to allow array (key/pair) as
input instead of many arguments.
4. Support of Date Object, they are the standard DateTime type in PHP.
It has to be done prior 1.0.0 and 5.3.0, date and time are the most
painful data to deal with in PHP. If intl and ext/date works hand in
hand it will give PHP a big kick in the date/time.
The advantages are obvious and many arguments and options can be
taken from a given instance (timezone for example).
5. Error management is rather unintuitive. I can't imagine to have to
check the error code after each call. Exceptions can greatly improve
it.
try {
$fmt = new NumberFormatter( 'fr_CH', ....);
echo $fmt->parse($num);
$mydate = new DateFormatter( "fr_FR" , ...);
$mydate->format($ts);
} catch (Exception $e) {
....
}
I can't imagine the mess if I start to use the result of a method as
arguments for other intl calls.
6. What's about a __toString implementation when possible. It may be
handy to use an instance in the views (templates or whatever one
uses as views) (). It can be done for all
three formatters (number, message and date) classes.
Prepare:
$invoice_line_amount = new NumberFormatter( 'fr_CH',
NumberFormatter::DECIMAL );
$invoice_line_amount->setValue($res);
View:
echo $invoice_line_amount;
Locale specific:
- Being able to parse, fetch and manage Locale IDs in a consistent and
portable way would rock, the ISO3 related API is a must have prior
1.0. It can be used from day #1 to normalize locale IDs format.
cheers,
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
