On Tue, Aug 23, 2016 at 9:03 AM, Ferenc Kovacs wrote:
> On Mon, Aug 22, 2016 at 6:30 PM, Christoph M. Becker
> wrote:
>
>> On 22.08.2016 at 18:00, Julien Pauli wrote:
>>
>> > I agree this is a BC break and should not stay as-is in source code.
>>
>> I wonder why we have more than 100 lines of "Ba
Anatol suggested I reach out to this group. I've been doing some of this
work in an informal capacity over the past few months
(design/coding/testing feedback on relevant PRs). I'd like to take on the
role officially. Besides the PR feedback, I'm working on improving the test
suite so it can be run
On Thu, Aug 25, 2016 at 8:12 PM, Christoph M. Becker
wrote:
> On 24.08.2016 at 18:45, Nikita Popov wrote:
>
> > On Aug 24, 2016 9:55 AM, "Davey Shafik" wrote:
> >>
> >> Given this thread: http://externals.io/thread/233
> >>
> >> I'm not happy with the state of this going into RC1 next week, and
Results for project PHP master, build date 2016-08-25 06:24:17+03:00
commit: 502fe5d
previous commit:6dccada
revision date: 2016-08-25 01:44:38+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
Am 23.08.2016 um 14:51 schrieb Julien Pauli:
> On Tue, Aug 23, 2016 at 1:51 PM, Christoph M. Becker
> wrote:
>
>> I suggest to deprecate all other types than NULL as first arg for static
>> methods, because passing an int, for instance, makes even less sense as
>> Rowan has already pointed out e
On 23.08.2016 at 17:03, Ferenc Kovacs wrote:
> personally I think that we are in general too lenient with allowing BC
> breaks in 7.1 (even though that I somehow expected this and was arguing for
> a longer release cycle for 7.0 or at least having a clear roadmap for the
> next major version) and
On 24.08.2016 at 18:45, Nikita Popov wrote:
> On Aug 24, 2016 9:55 AM, "Davey Shafik" wrote:
>>
>> Given this thread: http://externals.io/thread/233
>>
>> I'm not happy with the state of this going into RC1 next week, and without
>> changes (such as the patch I provided), I would like to revert t
On 16.08.2016 at 17:55, David Walker wrote:
> I raised this concept a couple weeks ago to a couple +1's. Discussion was
> held mostly upon the PR [1], and I went through and documented within the
> RFC [2]. I'd like to go ahead and open up the RFC to voting to the scope
> that it is written.
>
>
On 25/08/2016 12:10, Lester Caine wrote:
Is there any well documented alternative way of achieving the same
results as provided by these functions? Much of the time there is
on-list debates on how something should be done, but it gets somewhat
watered down in a migration guide ... if it makes it
On 25/08/16 08:00, Yasuo Ohgaki wrote:
> P.S. utf8_decode/encode are "Shouldn't use functions" as they make
> code non I18N needlessly. According to the code, original author's
> intention was to implement various encoding support. I guess this
> wouldn't happen anymore.
Is there any well document
Hi Rodrigue,
On Fri, Aug 19, 2016 at 10:45 PM, Rodrigue Villetard
wrote:
> First post here, so please be gentle and pedagogic with me if I am
> misbehaviouring…
>
> I am here for a pre-RFC feedback. It’s not coding related, but more about
> convention.
>
> I’m a follower of the french mailing lis
11 matches
Mail list logo
