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"); ?>
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
