On 13/06/2016 15:32, Joe Watkins wrote:
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 :)
Heh, fair enough. :)
I think a roadmap for PHP in general would be no bad thing, actually -
somewhere to plot out longer term goals, and a way to make future
releases more visible. At the moment, it's quite unusual to that might
be less true if there were a draft list of features for 7.2, and indeed 8.0.
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.
[...]
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.
This effort is absolutely appreciated, and I definitely don't want to
erect road blocks just for the sake of procedure.
That said, we do need to ensure we are on the same road, and that is
largely about communication. The last thing any of us wants is for
somebody to spend weeks working on an engine optimisation, then have it
conflict with what other people are trying to do at the language level.
This includes resisting the temptation to skip or fast-track processes,
and being clear in why a change is needed, and why it's needed now. The
more visibility there is of the big picture, the easier it becomes to
explain the details (e.g. "this change is necessary to progress the
project I was telling you about last month").
One idea that occurred to me was some form of regular update of what is
going on in engine development. Just a mail to the list a couple of
times a month saying "we have an interesting prototype of X; A is
working on a major refactoring of Y; B has managed to make Z 20% faster".
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.
It may be the policy that people have been following, but it's not the
policy that's written down. A "revised policy" doesn't have to mean
changing what we do; it could mean describing what is currently
happening in a new RFC, so that our documentation matches reality.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
