Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56490
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.49 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 10:31:48 +0100
Message-ID: <CAH-PCH5HbOqmVZucg-_aAXRySdemebU4kk1gHZxnyCz-qbwzag@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: multipart/alternative; boundary=20cf306f72fcd32e0004b26396ca
Subject: Re: [PHP-DEV] intl IDNA patch
From: tyra3l@gmail.com (Ferenc Kovacs)

--20cf306f72fcd32e0004b26396ca
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 23, 2011 at 10:26 AM, Stas Malyshev <smalyshev@sugarcrm.com>wro=
te:

> Hi!
>
>  Technically, yes, it is possible. But is it desirable? It would require
>> breaking the abstraction and looking at the actual values of the flags,
>> choosing one of the unused bits (possibly a high one) and hope it'll nev=
er
>> be used in future. Plus, in the current patch, the value of the variant
>> completely changes the return value (from string to array) so if it's mo=
re
>> appropriate to single it out.
>>
>
> 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.
>

Yeah, albeit low, there is still a chance that in the future we got some
clashing between their options and ours, so I think it would be better to
separate those.


>
> 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.
>
>  I don't really care or way or the other about pass-by-ref vs mixed retur=
n,
>> but I don't think your position on that issue is clear here, as you only
>> affirm that trying to force generic intl error reporting is not an optio=
n
>> (which I've also argued). If there are no objections, I'll advance with
>> mixed return, as Pierre has announced.
>>
>
> 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. I think for most use cases people would just use the string and i=
f
> the return is false they can either say "bad domain name" and be done wit=
h
> it, or parse the error codes and create special handling for each of them
> if they like. But I don't think there's a need to add so much complicatio=
n
> by making the same function return two types.


I thought that we already agreed using an output argument for getting the
specific error instead of returning either a string or an array.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--20cf306f72fcd32e0004b26396ca--