Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:36869
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.184.229 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=KfsIiv8Y0ihCxavqY9ng63b+q55yWCAUellEg6ldI5x4Zl/f0u6a0Qe3lD3pyEaSUwoOt2iq/45z+NthD64v/HQTXCS+lAaXQBi8tmDMeWPq0NZhtAudKr/96B+R/gwu9nQmp36tZCoR50vg0vjv4hF6EhRpmP2HUEmkPlcDOzo=
Message-ID: <fe05d1540804080541l732875cv8d9f5b7e22aacc06@mail.gmail.com>
Date: Tue, 8 Apr 2008 14:41:59 +0200
To: "Andi Gutmans" <andi@zend.com>
Cc: "Stas Malyshev" <stas@zend.com>, "Lester Caine" <lester@lsces.co.uk>, 
	"PHP internals" <internals@lists.php.net>
In-Reply-To: <698DE66518E7CA45812BD18E807866CE0175729A@us-ex1.zend.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <47F463F0.4030407@zend.com> <47F47360.8040606@lsces.co.uk>
	 <47F560E4.7060609@zend.com> <47F5DC3D.6090302@lsces.co.uk>
	 <47F677D9.4070804@zend.com>
	 <fe05d1540804041207o603e8d1cu149e83149471a2a1@mail.gmail.com>
	 <47F68136.8040908@zend.com>
	 <fe05d1540804041233l5e9f9b9cn88ef9bdef89123e1@mail.gmail.com>
	 <698DE66518E7CA45812BD18E807866CE0175729A@us-ex1.zend.net>
Subject: Re: [PHP-DEV] intl naming
From: pierre.php@gmail.com ("Pierre Joye")

Hi Stan, Andi and al!

On Fri, Apr 4, 2008 at 11:59 PM, Andi Gutmans <andi@zend.com> wrote:
> > -----Original Message-----
>  > From: Pierre Joye [mailto:pierre.php@gmail.com]
>  > 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