On 28 April 2015 at 15:10, Patrick ALLAERT <patrickalla...@php.net> wrote: > Le mar. 28 avr. 2015 à 20:42, Kalle Sommer Nielsen <ka...@php.net> a écrit : > >> I should probably have been faster at replying, but for PHP7 this is a >> no-go. I realize this is a pure internal change and have nothing to do >> with userland, but as currently is, we are in feature freeze and it >> creates a bad precedence between us as a team if we let this through >> now, sorry! >> > > "No go"? Isn't that a bit rough? > > That kind of change normally doesn't require an RFC at all. We did one for > documentation purpose instead of just a PR and a mail saying "ok for 7?".
I don't agree. This adds nine API functions and a few hundred lines of code: if you _had_ just committed this, I have no doubt that you'd have people asking you to revert it pending an RFC and a vote. This isn't a bug fix. Just because a feature is internal doesn't mean you can ignore the RFC process. RFCs aren't just for language features: if they were, Benjamin and I wouldn't have gone through the hassle of creating an RFC for making gc_collect_cycles hookable a few months ago. > Refusing this because we actually did an RFC to *document* it goes in the > opposite direction of encouraging people to create them. > > Isn't this just a documented "no brainer"? It's a good feature, the RFC is well written, and I have no doubt this would be accepted for PHP 7.1. Indeed, it's something I could actually make good use of in my day job. None of that is the point. We — as a development community — agreed to stop adding new features to PHP 7.0 on a certain date so that we could work on stabilising what we had and getting it out the door this year. That date was over a month ago. So, please, show respect for the people working hard on PHP 7.0 by not trying to push something in against our agreed processes and making more work for them. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
