Re: [RFC][DISCUSSION] Add preg_replace_callback_array function

Hey: On Mon, Mar 16, 2015 at 11:32 PM, Peter Cowburn <petercowburn@gmail.com> wrote: > On 16 March 2015 at 14:59, Xinchen Hui <laruence@php.net> wrote: > >> Hey: >> >> On Mon, Mar 16, 2015 at 5:45 PM, Peter Cowburn <petercowburn@gmail.com> >> wrote: >> > On 16 March 2015 at 01:40, Wei Dai <zxcvdavid@gmail.com> wrote: >> > >> >> 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()W� >> >> �b����)[�� that >> >> is the better way to Implement when there are multiple patterns need to >> >> replace. >> >> >> >> I would love to hear your feedback! :) >> >> >> > >> > Could you add a paragraph or two explaining the reasons for choosing this >> > particular proposal? >> > Some examples of what I would like to read: >> > - why we can't do preg_replace_callback($array_of_regexes, >> > $array_of_callbacks, $subject) >> array() also could be a valid callback.. (array("clasname", >> "methodname")). >> > - why not preg_replace_callback($array_of_regex_to_callback_pairs, >> > $subject) >> there are also $limit, $count argument could be used. >> > - why not pass the regex used to the callback, as per Laruence's earlier >> > RFC >> bc break..(change the callback's signature) >> > >> > And give a few links to historical discussions in the same sort of area? >> > E.g Laruence's RFC: >> > https://wiki.php.net/rfc/second_arg_to_preg_callback >> and >> > its discussion thread (http://php.markmail.org/thread/qwiyq5o2vwlbdczq). >> > >> thanks >> > > In case my earlier message wasn't clear, I was asking for the RFC itself to > be padded out with those sorts of details. The reason being, many (most) > people won't be already familiar with the surrounding discussions that have > happened previously, or the reasons for the potentially strange-seeming > design choices made in this RFC. hmm, yeah, it's better to have these in the RFC. I just replied in case Wei Dai is not familar with these reasons thanks > > >> > >> > >> > >> >> Any objections? >> >> >> >> >> >> — >> >> Best, >> >> Wei Dai >> >> >> >> >> >> >> >> -- >> Xinchen Hui >> @Laruence >> http://www.laruence.com/ >> -- Xinchen Hui @Laruence http://www.laruence.com/