Hi Dan, > On 04 Jan 2016, at 20:52, Dan Ackroyd <dan...@basereality.com> wrote: > > Are the wrong functions are listed in this sentence: "Emit an > E_DEPRECATED error whenever mb_ereg_replace_callback or > mb_eregi_replace_callback is called with the e option." As the RFC is > meant to be about mb_ereg_replace, mb_eregi_replace right?
Indeed. Thanks for spotting it. > The RFC doesn't say what functions people should use in place of the > deprecated functions. This needs to be laid out clearly. I can guess > what should happen for mb_ereg_replace, but there's not clear > replacement for mb_eregi_replace, as there is no > "mb_eregi_replace_callback" function. That ought to be thought about > and added to the RFC. That information is the section "Backward Incompatible Changes”, which admittedly may not be the most obvious place to look. To quote that section: “The suggested replacement, mb_ereg_replace_callback is has only been available since PHP 5.4.1. Projects which support both PHP 5.3 and PHP 7.1 may need two code paths to avoid deprecation warnings. There is no mb_eregi_replace_callback function. Code using it will have to be converted to use mb_ereg_replace_callbackwith the i option." >> The mandatory discussion period will end January 19th. > > That sentence is implying that you will put it to the vote as soon as > possible. Please don't do that. There is no rush to deprecate these > functions; the earliest they would actually be removed is years away, > and there needs to be a path guiding the people on how to replace that > functionality in place before we deprecate them. The implication wasn’t my attention. It was mostly a reminder for myself how long I have to keep the discussion open. That said, I hope this isn’t controversial due to the similar RFC about pre_replace passing 4 years ago. Best regards Rouven -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
