Hi Sebastian,
On Sun, Mar 22, 2015 at 2:05 AM, Sebastian Bergmann
wrote:
> Am 15.03.2015 um 08:27 schrieb Sebastian Bergmann:
>
>> It was my idea, after all, only fair that I invest the time to make
>> it into an RFC: https://wiki.php.net/rfc/throwable
>>
>
> The vote for this missed the boat f
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
Hi everybody!
In the Wiki there's a section with RFCs targeting PHP 5.7[1].
Obviously, this section should be merged into the PHP 7.0 section. I
will do so, if there are no objections.
However, the "Fix handling of custom session handler return values"
RFC[2] still says "Status: Voting" even tho
On Sun, Mar 15, 2015 at 4:46 PM, Nikita Popov wrote:
> Hi internals!
>
> To ensure we have no shortage of new RFC votes...
>
> https://wiki.php.net/rfc/reclassify_e_strict#vote
>
> Voting is open for ten days :)
>
RFC is accepted with 28 votes in favor and 4 against.
Nikita
> 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
Hi, I was late closing the vote on rfc:continue_ob, but there was only
one yay in the last two days, anyway.
The change was accepted with 100% yes votes, and has just been committed.
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.
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
14 matches
Mail list logo