回复： [PHP-DEV] [RFC][DISCUSSION] Add preg_replace_callback_array function

Hi Peter: Sorry to reply late, because the GFW, I can’t access *.google.com at home. > > > On 16 March 2015 at 14:59, Xinchen Hui <laruence@php.net (mailto:laruence@php.net)> > wrote: > > Hey: > > > > On Mon, Mar 16, 2015 at 5:45 PM, Peter Cowburn <petercowburn@gmail.com > > (mailto:petercowburn@gmail.com)> wrote: > > > On 16 March 2015 at 01:40, Wei Dai <zxcvdavid@gmail.com > > > (mailto: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() 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 > I accept, and I will be add these details in RFC. > > 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. Thanks for the suggestion. :) > > > > > > > > > > > > > Any objections? > > > > > > > > > > > > — > > > > Best, > > > > Wei Dai > > > > > > > > > > > > > -- > > Xinchen Hui > > @Laruence > > http://www.laruence.com/ > — Wei Dai