On 21 March 2015 at 12:30, Peter Cowburn <petercowb...@gmail.com> wrote:
> On 21 March 2015 at 08:14, Xinchen Hui <larue...@php.net> wrote: > > > Hey: > > > > On Fri, Mar 20, 2015 at 9:14 PM, Xinchen Hui <larue...@php.net> wrote: > > > Hey: > > > > > > On Fri, Mar 20, 2015 at 7:53 PM, Alain Williams <a...@phcomp.co.uk> > > wrote: > > >> On Fri, Mar 20, 2015 at 10:46:58PM +1100, Pierre Joye wrote: > > >>> On Fri, Mar 20, 2015 at 7:03 PM, Wei Dai <zxcvda...@gmail.com> > wrote: > > >>> > Hi internals, > > >>> >> Hi internals, > > >>> >> > > >>> >> The RFC to add a user-land function for an easy-to-use and > reliable > > >>> >> preg_replace_callback_array() in PHP is up for discussion: > > >>> >> https://wiki.php.net/rfc/preg_replace_callback_array > > >>> >> > > >>> >> This proposes adding one function: `preg_replace_callback_array()` > > that > > >>> >> is the better way to Implement when there are multiple patterns > > need to > > >>> >> replace. > > >>> >> > > >>> >> I would love to hear your feedback! :) > > >>> >> Any objections? > > >>> > > > >>> > I’ve sent this mail for four days, I don’t know if this RFC needs a > > vote. > > >>> > If you guys have no objections on this, please review the code and > > merge it, > > >>> > thanks. > > >>> > > >>> Nice job, i like the idea. > > >>> > > >>> I am not sure about a RFC or not. It somehow looks like a sane > > >>> replacement for something we killed (with good reasons). > > >>> > > >>> Let see what the other think :) > > >> > > >> I used s/something/code/ge in a perl script that I wrote a few days > > ago. Very > > >> useful. It would have been a lot more work to do it another way. > > >> > > >> So: +1 to the ability to do this, regardless of what mechanism is > > eventually chosen. > > > > > > I also +1 for this. > > > > > > if there is no objections raises, I am going to merge it tomorrow.. > > merged > > > > thanks > > > > > > Whoa, hold on there a second. > > An RFC was created, presumably intending to follow that line of procedure. > Then Xinchen comes along and puts a middle finger up to the whole process, > reverts back to the old "if no-one complains by tomorrow, merge it" > approach, then does the merge. > > I'm all for avoiding the potentially unnecessary red tape of the RFC > process. Particularly for small, standalone changes like this. I fear there > are other who aren't so lenient. > > Thoughts?.. > Yep, this does look like another case of simply ignoring rules. The fact that what does and does not require an RFC does not help, this probably didn't need one, however one was created and the rules need to be stuck to. Instead of forcing this change to be reverted, because it really is self-contained, we need a succinct wiki document on what does and doesn't require an RFC.