On Tue, Mar 31, 2015 at 3:02 PM, Tony Marston wrote:
> "Nikita Popov" wrote in message
> news:CAF+90c9ZCE4rrdtwoqwnBE=u_s4asxhu4n_jia+40oy_gum...@mail.gmail.com...
>
>>
>> On Fri, Mar 27, 2015 at 11:11 PM, Stanislav Malyshev
>> wrote:
>>
>>> Hi!
>>>
>>> I was never happy about this particular ha
"Nikita Popov" wrote in message
news:CAF+90c9ZCE4rrdtwoqwnBE=u_s4asxhu4n_jia+40oy_gum...@mail.gmail.com...
On Fri, Mar 27, 2015 at 11:11 PM, Stanislav Malyshev
wrote:
Hi!
I was never happy about this particular hack but that said, unless we
*know* it is not used widely (and I suspect it is
On Mar 30, 2015 5:29 PM, "Nikita Popov" wrote:
> From this thread, I'd say we have a consensus to deprecate it. From the
> Japanese side, both Yasuo and Masaki agree that this should be dropped and
> Masaki also linked a bug report where it is stated that the original
author
> of this functionali
On Fri, Mar 27, 2015 at 11:11 PM, Stanislav Malyshev
wrote:
> Hi!
>
> I was never happy about this particular hack but that said, unless we
> *know* it is not used widely (and I suspect it is in Japan etc. where we
> don't have a lot of visibility due to language barrier) we can't really
> remove
Hi!
I was never happy about this particular hack but that said, unless we
*know* it is not used widely (and I suspect it is in Japan etc. where we
don't have a lot of visibility due to language barrier) we can't really
remove it.
Also, I'm not sure why should we remove it. Yes, it's a PITA for th
Hi all,
On Wed, Mar 25, 2015 at 12:25 AM, Zeev Suraski wrote:
> I think we need to understand how it's actually being used before
> discussing
> its deprecation. IIRC it's extremely widely used in Japan, but could be
> wrong.
> I'd want to hear from our Japanese contributors what their thoughts
> De : Rowan Collins [mailto:rowan.coll...@gmail.com]
>
> I think there should be a quick RFC collecting this reasoning, and a
> formal invitation for contrary opinions, to avoid accusations that it
> was slipped in the back door. If there really is no opposition, the RFC
> will record that the vot
On 25 March 2015 at 14:32, Rowan Collins wrote:
> Chris Wright wrote on 25/03/2015 13:44:
>
>> That said, in the interests of not causing people using this functionality
>> issues with logs full of errors and/or error-related performance issues, I
>> would support having this deprecation set up i
Chris Wright wrote on 25/03/2015 13:44:
That said, in the interests of not causing people using this functionality
issues with logs full of errors and/or error-related performance issues, I
would support having this deprecation set up in such a way that an error is
only issued at most once per re
On 25 March 2015 at 09:22, Tony Marston wrote:
> "Zeev Suraski" wrote in message news:66c0cca2453de53bed0328af2732c7
> b...@mail.gmail.com...
>
>
>> -Original Message-
>>> From: Nikita Popov [mailto:nikita@gmail.com]
>>> Sent: Tuesday, March 24, 2015 4:45 AM
>>> To: PHP internals
>>
Pierre Joye wrote on 25/03/2015 13:19:
On Wed, Mar 25, 2015 at 1:35 PM, Rowan Collins wrote:
Levi Morrison wrote on 24/03/2015 20:35:
On Tue, Mar 24, 2015 at 11:30 AM, Rowan Collins
wrote:
François Laupretre wrote on 24/03/2015 16:30:
De : Bob Weinand [mailto:bobw...@hotmail.com]
No, he i
On Wed, Mar 25, 2015 at 1:35 PM, Rowan Collins wrote:
> Levi Morrison wrote on 24/03/2015 20:35:
>
>> On Tue, Mar 24, 2015 at 11:30 AM, Rowan Collins
>> wrote:
>>>
>>> François Laupretre wrote on 24/03/2015 16:30:
>
> De : Bob Weinand [mailto:bobw...@hotmail.com]
>
> No, he isn't
Masaki Kagaya wrote on 25/03/2015 02:47:
Rui agreed the deprecation and Yasuo gave notice to PHP internal in April
2012.
https://bugs.php.net/bug.php?id=65785
http://marc.info/?l=php-internals&m=133548185505478&w=2
In that case, it's a shame that wasn't followed through with an RFC at
the tim
Levi Morrison wrote on 24/03/2015 20:35:
On Tue, Mar 24, 2015 at 11:30 AM, Rowan Collins wrote:
François Laupretre wrote on 24/03/2015 16:30:
De : Bob Weinand [mailto:bobw...@hotmail.com]
No, he isn't asking for delaying the timeline. He's asking if we can do
this
without RFC. Minimal self-co
"Zeev Suraski" wrote in message
news:66c0cca2453de53bed0328af2732c...@mail.gmail.com...
-Original Message-
From: Nikita Popov [mailto:nikita@gmail.com]
Sent: Tuesday, March 24, 2015 4:45 AM
To: PHP internals
Subject: [PHP-DEV] Deprecate or remove mbstring function overloads in PHP
On Wed, Mar 25, 2015 at 9:47 AM, Masaki Kagaya wrote:
> Rui agreed the deprecation and Yasuo gave notice to PHP internal in April
> 2012.
>
> https://bugs.php.net/bug.php?id=65785
> http://marc.info/?l=php-internals&m=133548185505478&w=2
Deprecation is fine and I am sure we will have more until w
Rui agreed the deprecation and Yasuo gave notice to PHP internal in April
2012.
https://bugs.php.net/bug.php?id=65785
http://marc.info/?l=php-internals&m=133548185505478&w=2
2015-03-25 0:25 GMT+09:00 Zeev Suraski :
> > -Original Message-
> > From: Nikita Popov [mailto:nikita@gmail.c
On Tue, Mar 24, 2015 at 11:30 AM, Rowan Collins wrote:
> François Laupretre wrote on 24/03/2015 16:30:
>>>
>>> De : Bob Weinand [mailto:bobw...@hotmail.com]
>>>
>>> No, he isn't asking for delaying the timeline. He's asking if we can do
>>> this
>>> without RFC. Minimal self-contained changes don'
François Laupretre wrote on 24/03/2015 16:30:
De : Bob Weinand [mailto:bobw...@hotmail.com]
No, he isn't asking for delaying the timeline. He's asking if we can do this
without RFC. Minimal self-contained changes don't need a RFC and can go as
well into alpha/beta phase without issues.
Sorry, I
> De : Bob Weinand [mailto:bobw...@hotmail.com]
>
> No, he isn't asking for delaying the timeline. He's asking if we can do this
> without RFC. Minimal self-contained changes don't need a RFC and can go as
> well into alpha/beta phase without issues.
Sorry, I don't understand when a change is supp
> -Original Message-
> From: Nikita Popov [mailto:nikita@gmail.com]
> Sent: Tuesday, March 24, 2015 4:45 AM
> To: PHP internals
> Subject: [PHP-DEV] Deprecate or remove mbstring function overloads in PHP
> 7
>
> Hi internals!
>
> The mbstring extension supports replacing PHP string func
> Am 24.03.2015 um 14:39 schrieb François Laupretre :
>
>> De : Nikita Popov [mailto:nikita@gmail.com]
>>
>> The mbstring extension supports replacing PHP string functions with
>> multibyte variants through the mbstring.func_overload ini option.
>>
>> This ini setting is a real PITA for code
Hi
2015-03-24 14:39 GMT+01:00 François Laupretre :
> Probably fine, but how does your suggestion fit in the PHP 7 timeline ? The
> BC break requires it is introduced in 7.0. And it is too late for this. As
> everyone seems to be against delaying the timeline, I hope we won't accept
> exceptions
> De : Nikita Popov [mailto:nikita@gmail.com]
>
> The mbstring extension supports replacing PHP string functions with
> multibyte variants through the mbstring.func_overload ini option.
>
> This ini setting is a real PITA for code compatibility, as it makes it
> impossible to rely on the outpu
24 matches
Mail list logo
