Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56488
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.203 as permitted sender)
Message-ID: <4ECCBC37.9060106@sugarcrm.com>
Date: Wed, 23 Nov 2011 01:26:15 -0800
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Gustavo Lopes <glopes@nebm.ist.utl.pt>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <4ECC9ABE.1010709@sugarcrm.com> <op.v5d533h2idpuyk@cataphract.cata.lo.geleia.net>
In-Reply-To: <op.v5d533h2idpuyk@cataphract.cata.lo.geleia.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] intl IDNA patch
From: smalyshev@sugarcrm.com (Stas Malyshev)

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 never
> 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 more
> 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.

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 return,
> 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 option
> (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 
if the return is false they can either say "bad domain name" and be done 
with 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 
complication by making the same function return two types.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227