Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56496
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4ECCBC37.9060106@sugarcrm.com>
References: <4ECC9ABE.1010709@sugarcrm.com>
	<op.v5d533h2idpuyk@cataphract.cata.lo.geleia.net>
	<4ECCBC37.9060106@sugarcrm.com>
Date: Wed, 23 Nov 2011 11:27:11 +0100
Message-ID: <CAEZPtU6ZcbBqc7DS8ck8k0h5gYuFrDWO7cjN8s2LfKqsMqQDww@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Gustavo Lopes <glopes@nebm.ist.utl.pt>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] intl IDNA patch
From: pierre.php@gmail.com (Pierre Joye)

On Wed, Nov 23, 2011 at 10:26 AM, Stas Malyshev <smalyshev@sugarcrm.com> wrote:

> I think yes, it's better to have one options set than "options" and "another
> options which aren't first options but different options". I don't think
> there's breaking of abstraction if we use more options that ICU has, and
> probability of ICU using all 32 bits seems quite low for me now.
>
> I don't think we should return array there - it makes using the function
> much more awkward since you need to check options before you know what it
> returns. I think it's better to have normal return always a string, abnormal
> can be handled by a special value if the user cares.

yes, see my reply. We agreed that these functions should always return
a string or false (on error).

Which kind of action will be take is defined by the new argument, and
possible errors can be returned using the last new argument (array by
ref). It is however important to give the caller a way to deal with
the possible warnings or errors.

> Actually, that's what I was objecting to. I think mixed return (i.e.
> function returning array or string depending on option) is not the best
> option.

That's not what we agreed on. I did not check the last version of the
patch but we agreed on string|false only as return value :)


Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org