Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:36881
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.162.179 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=CRC0l9onHkMDdoDnOkql6UrLoZiJZsYiqo5bXhj728pJ7K/UabNX45v5KomsqmfbUh6pljIO1sEG1inqZFajeAy6VvduuG6iI3Pysve9XwVxvfx+D/wIB0nyX6lRSxmuWAuCxuZ9mm+Cw8hH/hkGFysyuh+ViqZoFbbdOmfKJoY=
Message-ID: <fe05d1540804081209l68916e9ey4b0a68bec255f7e1@mail.gmail.com>
Date: Tue, 8 Apr 2008 21:09:19 +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: <47FBBF0F.4080505@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> <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>
	 <fe05d1540804081140q3fd5a0a8rcb2d0b93a066a531@mail.gmail.com>
	 <47FBBF0F.4080505@zend.com>
Subject: Re: [PHP-DEV] intl naming
From: pierre.php@gmail.com ("Pierre Joye")

Hi!

On Tue, Apr 8, 2008 at 8:53 PM, Stanislav Malyshev <stas@zend.com> wrote:

> > 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)?
> >
>
>  Locale::setDefault() and Locale::DEFAULT.

Damned, I missed it four times :) It is not present in the synopsis
but in the methods list.

Then I really don't understand the current methods signature. The
locale should be optional and obivously not as first argument.

> > That's why I would prefer an array (as named arguments). The keys
> >
>
>  We aimed to create a wrapper for ICU, not reinvent how PHP language works.
> So we accept arguments the usual way - through function parameters, not
> through arrays.

You may aim to create a thin wrapper around ICU, but we aim to create
the best possible i18n API. :-)

There is many API using this method when there is too many arguments,
when the risk of confusions is high.

About creating a wrapper, that's actually part of the solution to do
not create a thin wrapper but to add some "intelligence" in the
extension to ease its usage. It is even more important for APIs like
what intl try to do as it will be used by almost everyone out there.

> > 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
> >
>
>  I guess that's a matter of personal taste.


No, that's a matter of being able to use a default locale without
passing NULL or an empty string. That's really bad practice to have an
optional argument as first argument.

> > 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.
> >
>
>  Well, the thoughts here are pretty simple - where date formatting functions
> accept timestamp and localtime array, they should accept DateTime object
> too. Also, there should be parse function returning DateTime, like one that
> returns timestamp. I think if you look in CVS in doc folder, early versions
> of date formatter API mention that.

Thanks for the hint, I will take a look at the history.

> > 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.).
> >
>
>  You mean create API translating from language name in given locale to
> language code? I'm not sure ICU has this API. Locale class allows you to get
> components and display strings for the locales, but you have to have locale
> IDs first. There also are some matching functions in Locale, but I don't see
> any ICU functions allowing you to know IDs from external information, only
> to choose from set of IDs and enquire about ID.
>
>  As for validity, since locale mechanism has a bunch of fallbacks, I
> understand the validity concept is a bit blurred. I.e. you can have regexp
> to check all the -'s or _'s are in place but beyond that it's kind of hard
> to know what the question "is en_RU locale valid?" means.

It is amazingly handy to know that a locale given by the user (UI or a
developer using your library) is valid. What I like to have are
getCountry, getISO3* etc. I can provide a list and then a patch.


-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org