Re: Re: str_ireplace vs. stri_replace

On Thu, 30 Jan 2003, Sara Golemon wrote: SG>>> > > +1 from me too, stri_replace sound like a function some users may have SG>>> > > SG>>> > > implemented them selves and we could end up breaking their code by SG>>> > > introducing it. SG>>> > SG>>> > exactly :). SG>>> > SG>>> Only one complaint. SG>>> SG>>> Previously (including in 4.3.0) there already WAS a fourth (undocumented) SG>>> parameter to str_replace. A boolean value which would allow the user to use SG>>> an alternate search and replace method. True, this was undocumented, and SG>>> was probably only included for developer debugging (Sascha? Can you SG>>> enlighten us?). [...] SG>>> If we introduce a *new* fourth parametere (also boolean) which checks for SG>>> case_sensitivity, this could potentially cause problems for users who were SG>>> using this undocumented parameter. Leaving the fourth and adding a fifth SG>>> would get even more confusing if the appearance is that the fourth parameter SG>>> was just added *and* served no purpose. FWIW: Given this mess, and the fact that any php-coded stri_replace can be overloaded, I think a new function is better. Also - it's in sync with the other stri* functions. Either change all with a case-insensativity paramenter, or keep the namingconventions that 'plague' these functions. -- With kind regards, Melvyn Sopacua <?php include("not_reflecting_employers_views.txt"); ?>