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.coll...@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] >
