On Wed, Nov 23, 2011 at 10:26 AM, Stas Malyshev <smalys...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
