Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93939
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.213.46 cause and error)
MIME-Version: 1.0
In-Reply-To: <c780790b-fe68-820a-8a5b-0e69fdce5d5e@gmail.com>
References: <6c03dafd-093a-0087-6312-96fede93c5f0@gmail.com>
	<CAH-PCH5e6_aTCQEPd8=B0sFwsWsDfaG+2Fsp4i93t3qmxgmQQQ@mail.gmail.com>
	<020a01d1c501$3d3d9420$b7b8bc60$@php.net>
	<CAL=_i_mibDngeQ3-ejhxCUCQmWSYivdgrvoFFZyKAJ6H63Twmg@mail.gmail.com>
	<c780790b-fe68-820a-8a5b-0e69fdce5d5e@gmail.com>
Date: Mon, 13 Jun 2016 15:32:38 +0100
Message-ID: <CAL=_i_nxLUz_1xiS3EAr=v8PcSdoSapkWe46LEv4snFH__dbuA@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: Anatol Belski <ab@php.net>, Ferenc Kovacs <tyra3l@gmail.com>, Joe Watkins <krakjoe@php.net>, 
	Davey Shafik <davey@php.net>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114e52f2a34ab4053529c2b9
Subject: Re: [PHP-DEV] Is the "No BC Breaks in Minor Releases" policy enforceable?
From: pthreads@pthreads.org (Joe Watkins)

--001a114e52f2a34ab4053529c2b9
Content-Type: text/plain; charset=UTF-8

Afternoon internals,

> Is there a roadmap somewhere that describes this, or any background
discussion of doing this within the 7.x series, rather than planning for
8.0?

We have no such sensible thing as a plan :)

The reason for the existence of PHP 7 (ng) is efficiency of the kind I
described, this is surely well understood by everyone.

What may not be well understood is that the job is nothing like complete.
Vigilant observers will have noticed that Dmitry does indeed have a JIT for
NG, which is very useful research, but it sucks so hard that we can't
deploy it.

The reason for this is that, in part, generated code doesn't look so much
different to code executed by the VM, though details differ considerably;
It needs to do at least the same job, it may need to do more (because of
guarding and other boring things).

Without knowing anything about generating instructions anyone can tell that
a complicated Zend, with all kinds of edge cases and inconsistencies
(specifically regarding ZE) is going to necessitate the generation of
complicated code, to accommodate those edge cases and inconsistencies.

A lot of effort is being put in to finding and resolving inconsistencies in
the engine such as this, a lot of effort has been expended and will be
expended on 7 in the pursuit of efficiency. A lot of this is of no
consequence to BC.

You can count the number of people putting in the majority of this effort
on your fingers ... erecting a road block in front of them in the name of
unobtainable BC is harmful to the apparent goals of the project at this
time.

The kinds of changes that must be delayed until 8.0 are surely going to be
proposed, and we will surely delay them by consensus.

> This is my main concern, also

I will update the RFC, if Dmitry doesn't, when voting is closed.

I will ensure the change is properly documented in the manual also.

> Ideally, this could lead to a revised policy

I think our policy has always been to consider each proposal on a
case-by-case basis. That's all I have done, and all I am suggesting others
do.

I know it's very strange to hear someone talking about "goals" ...

We can waste a bunch of time trying to define them, voting on them, and so
on ... or, we can look at what is going on, and what has gone on, and come
to sensible conclusions.

Cheers
Joe



On Mon, Jun 13, 2016 at 1:28 PM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> On 13/06/2016 10:35, Joe Watkins wrote:
>
>>     Backward compatibility is important. Also important is the long term
>> goals for PHP, or at least for this major version of PHP: The goal is to
>> make Zend so efficient that generating machine code from user code
>> becomes a deployable solution.
>>
>
> OK, that's an interesting bit of background, which might explain why
> Dmitry seemed in a hurry to get this in place. I was aware of the
> discussion of performance, but not the background "long-term goal". Is
> there a roadmap somewhere that describes this, or any background discussion
> of doing this within the 7.x series, rather than planning for 8.0?
>
>
>     I can be wrong, might be ... it doesn't really matter, the majority
>> has spoken. It is only my concern that the change is documented properly.
>>
>
> This is my main concern, also. The RFC is very brief, and the discussion
> period was artificially shortened, and I think the implications to the BC
> policy make this RFC more important than Dmitry assumed.
>
> Having a documented reason why a BC break was accepted in this case will
> help to set expectations in the future. Ideally, this could lead to a
> revised policy with BC guidelines that actually match the current reality
> of the project, which the existing RFC does not seem to do.
>
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>

--001a114e52f2a34ab4053529c2b9--