Hi!
I've committed support for UTS #46 to 5.4 and trunk.
See http://svn.php.net/viewvc?view=revision&revision=319770
Could you please also fix the protos on the functions? And updating the
docs would be ideal :)
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(
hi Gustavo!
Thanks!
can you add a note to UPGRADING and in the bug report please?
Cheers,
On Thu, Nov 24, 2011 at 6:58 PM, Gustavo Lopes wrote:
> I've committed support for UTS #46 to 5.4 and trunk.
>
> See http://svn.php.net/viewvc?view=revision&revision=319770
>
> --
> Gustavo Lopes
>
> --
I've committed support for UTS #46 to 5.4 and trunk.
See http://svn.php.net/viewvc?view=revision&revision=319770
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, Nov 23, 2011 at 10:26 AM, Stas Malyshev 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
On Wed, Nov 23, 2011 at 10:47 AM, Ferenc Kovacs wrote:
>
>
> On Wed, Nov 23, 2011 at 10:36 AM, Stas Malyshev wrote:
>
>> Hi!
>>
>>
>> I thought that we already agreed using an output argument for getting
>>> the specific error instead of returning either a string or an array.
>>>
>>
>> That's wh
On Wed, Nov 23, 2011 at 10:36 AM, Stas Malyshev wrote:
> Hi!
>
>
> I thought that we already agreed using an output argument for getting
>> the specific error instead of returning either a string or an array.
>>
>
> That's what I was thinking too, but Gustavo seems to plan to do mixed
> return, w
Hi!
I thought that we already agreed using an output argument for getting
the specific error instead of returning either a string or an array.
That's what I was thinking too, but Gustavo seems to plan to do mixed
return, which I think is a worse option.
--
Stanislav Malyshev, Software Archit
On Wed, Nov 23, 2011 at 10:26 AM, Stas Malyshev 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 u
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
c
On Wed, 23 Nov 2011 07:03:26 -, Stas Malyshev
wrote:
1. I'm not sure I understand why we need two options fields. We already
have one options field, won't that be enough? We can combine options and
space them in a way that old ones work fine with new ones, can't we?
And have default v
Hi!
First of all, I would like to politely ask everybody on the list to
change subject if, well, subject of the discussion changes. I was
totally under impression that this topic still discusses libidn2
extension in PECL and might miss discussion about intl IDNA patch if
David didn't point it
11 matches
Mail list logo
