On Wed, Nov 23, 2011 at 10:26 AM, Stas Malyshev <smalys...@sugarcrm.com>wrote:
> 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. > 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 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. I thought that we already agreed using an output argument for getting the specific error instead of returning either a string or an array. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
