Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:36878
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.170.184 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=NHhBwSMYS0JfpLy9kqAeKHvrYJYObfFycOBJXobCo8GPtQAR0JTeqZOp1/hEkRXbWzB/BBbuQ/YdmFeUq+22dz55OUdg4yefeGoalEACOtoS6bZD5OCJyTOQncMSLMA4dPZ/zup9dRvu0fGgG/1Zb7DkNMfu3fu9uF2jQIf/mSg=
Message-ID: <fe05d1540804081140q3fd5a0a8rcb2d0b93a066a531@mail.gmail.com>
Date: Tue, 8 Apr 2008 20:40:26 +0200
To: "Stanislav Malyshev" <stas@zend.com>
Cc: "Andi Gutmans" <andi@zend.com>, "Lester Caine" <lester@lsces.co.uk>, 
	"PHP internals" <internals@lists.php.net>
In-Reply-To: <47FBA5A7.1070600@zend.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <47F463F0.4030407@zend.com> <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>
	 <fe05d1540804080541l732875cv8d9f5b7e22aacc06@mail.gmail.com>
	 <47FBA5A7.1070600@zend.com>
Subject: Re: [PHP-DEV] intl naming
From: pierre.php@gmail.com ("Pierre Joye")

Hi Stan,

On Tue, Apr 8, 2008 at 7:04 PM, Stanislav Malyshev <stas@zend.com> wrote:
> >   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().
> >
>
>  You can use default locale, of course, and Locale class already has these
> functions. http://docs.php.net/manual/en/class.locale.php

I did not find a way to do it in the manual or in the code. How do I
set in PHP? And how is it possible to use it as default for all
further calls (no matter which class/method)?

> >   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).
> >
>
>  I'm afraid that wouldn't work since functions have variable number of
> arguments and we want consistent API across all modules.

That's why I would prefer an array (as named arguments). The keys
(names) are easy to remember. You can even support both. I'm ready to
provide a patch to support array as input (with default values
support) if we agree on that.

> >   Arguments order may be confusing and hard to remember. However their
> >
>
>  Like "locale goes first"?

The locale as 1st argument always looked weird to me when I was
writing my test code. The reason is certainly because of the default
locale not being set or used. As it is possible (if I understand you
correctly) I don't see why it has to be as first argument, one will
always has to pass it (NULL/"" or a valid locale id).

> > 4. Support of Date Object, they are the standard DateTime type in PHP.
> >
>
>  Planned to be done later - if anybody wants to contribute now, please do.
> It is indeed very important, we just don't have somebody to do it right now.

If right now is not within days but within 2 weeks, I can try to do
it. But I first like to hear Derick's idea on the topic before. Please
let us know your thoughts (wiki?) about this topic, it will certainly
spare us some precious time.


> > 5. Error management is rather unintuitive. I can't imagine to have to
> >   check the error code after each call. Exceptions can greatly improve
> >
>
>  Like 99% people do with 99% functions in PHP? You must be really suffering
> not writing code in Java :)

Where did you get these numbers? For what I see nowadays, it is more a
high percentage with OO for everything but some basic helpers.
However, the point is not about OO or not OO but to do not duplicate
the API without any gain. Locale::foo() is as easy to write or read
than locale_foo().

> > 6. What's about a __toString implementation when possible. It may be
> >
>
>  If you can propose good toString - and especially if you have volunteer to
> implement it :) - why not? We didn't have good use for toString, but if you
> find one - welcome.

I will think about it a bit more. But that will rock to have it :)

> >   Prepare:
> >   $invoice_line_amount = new NumberFormatter( 'fr_CH',
> > NumberFormatter::DECIMAL );
> >   $invoice_line_amount->setValue($res);
> >
> >   View:
> >   echo $invoice_line_amount;
> >
>
>  We didn't purport to implement yet another MVC templating system here. We
> wrote ICU wrapper.

I was not clear, sorry. The goal is not to create a MVC but to allow
easy and user friendly usage without having to use intermediate string
variable or other custom objects.

> > 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.
> >
>
>  Could you elaborate? I think our functions understand locales in standard
> formats, but maybe you mean something else.

The idea is to have a way to get a code for a language, or to valid a
given code, etc. Many applications actually duplicate this list
internally, it would be very nice to be able to deal with the ICU
lists (display, validation, listings, etc.).

Cheers,
-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org