[PHP-DEV] Re: str_ireplace vs. stri_replace
Ilia A. writes: 1. Not all users will notice the extra parameter easily. Will take some time. This modification will not appear until PHP 5 is released, by then this extra parameter (hopefully) will be well documented and people will be aware that it exists. Adding extra code, which virtually does the same thing IMHO is pointless and only creates a messy code that is difficult to maintain at a future point. 2. If some users made their own function called stri_replace, this is nothing that should be stopping from implementing it officially. In fact, to fix it would be as easy as encapsuling the function declaration in You are correct in the event of a user writing a new function, however consider what will happen if we are dealing with a old code, especially if it is no longer used just by the author but rather by a variety of other people not familiar with PHP code. The result is that after they or their ISPs upgrade to new PHP their scripts will stop working. Yes, but you are talking about a few dozen of cases forgetting thousands of newbies that are seeking for stri_replace function... They aren't guessing whether this time there a forth parameter in str_replace ... I think a logical function set is better for consistency... especially when strstr has stristr, ereg* has eregi* and so on... At the end, releasing PHP all of the sudden with register_globals off by default a year ago made much more damage worldwide... That was a change for PHP5, not in the middle of the releases... But, the reason was good - security. This little change (str(i?)_replace) only asks for removing user defined functions because the official one exists... Once *ALL* PHP users passed through register_globals, I think another dozen of them can go through stri_replace prob :) Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: str_ireplace vs. stri_replace
On Thu, 30 Jan 2003, Jon Parise wrote: On Thu, Jan 30, 2003 at 01:44:27PM -0800, Sara Golemon wrote: You're not the first to voice this opinion. *I* feel str_ireplace is better as it follows the naming convention of module_function. Others feel stri_replace is better as that follows eregi_replace's style. I have no trouble going with whatever the majority feels is best. Get rid of stri_replace() and/or str_ireplace() and just add a fourth optional parameter to str_replace() to control case-sensitivity. +1 on that. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: str_ireplace vs. stri_replace
On January 30, 2003 04:55 pm, Jon Parise wrote: On Thu, Jan 30, 2003 at 01:44:27PM -0800, Sara Golemon wrote: You're not the first to voice this opinion. *I* feel str_ireplace is better as it follows the naming convention of module_function. Others feel stri_replace is better as that follows eregi_replace's style. I have no trouble going with whatever the majority feels is best. Get rid of stri_replace() and/or str_ireplace() and just add a fourth optional parameter to str_replace() to control case-sensitivity. +1 from me too, stri_replace sound like a function some users may have implemented them selves and we could end up breaking their code by introducing it. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: str_ireplace vs. stri_replace
Adding a parameter to an existing function is the way to go I agree. Timothy Hitchens (HiTCHO) Web Application Consulting e-mail: [EMAIL PROTECTED] -Original Message- From: Derick Rethans [mailto:[EMAIL PROTECTED]] Sent: Friday, 31 January 2003 8:00 AM To: Jon Parise Cc: Sara Golemon; PHP Developers Mailing List Subject: Re: [PHP-DEV] Re: str_ireplace vs. stri_replace On Thu, 30 Jan 2003, Jon Parise wrote: On Thu, Jan 30, 2003 at 01:44:27PM -0800, Sara Golemon wrote: You're not the first to voice this opinion. *I* feel str_ireplace is better as it follows the naming convention of module_function. Others feel stri_replace is better as that follows eregi_replace's style. I have no trouble going with whatever the majority feels is best. Get rid of stri_replace() and/or str_ireplace() and just add a fourth optional parameter to str_replace() to control case-sensitivity. +1 on that. Derick -- -- --- Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ -- --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: str_ireplace vs. stri_replace
On Thu, 30 Jan 2003 17:11:53 -0500 Ilia A. [EMAIL PROTECTED] wrote: +1 from me too, stri_replace sound like a function some users may have implemented them selves and we could end up breaking their code by introducing it. exactly :). And why introduce function name with no respect of naming convention ? I read many times here that we do not have to do it this way O:-) anyway... pierre -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: str_ireplace vs. stri_replace
Jon Parise writes: Get rid of stri_replace() and/or str_ireplace() and just add a fourth optional parameter to str_replace() to control case-sensitivity. Yup. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: str_ireplace vs. stri_replace
+1 from me too, stri_replace sound like a function some users may have implemented them selves and we could end up breaking their code by introducing it. exactly :). Only one complaint. Previously (including in 4.3.0) there already WAS a fourth (undocumented) parameter to str_replace. A boolean value which would allow the user to use an alternate search and replace method. True, this was undocumented, and was probably only included for developer debugging (Sascha? Can you enlighten us?). This alternate method has been removed (by virtue of being deprecated) and should produce wrong param count errors for users who include that fourth parameter currently (how many would even know of this?) so that they can fix their code. If we introduce a *new* fourth parametere (also boolean) which checks for case_sensitivity, this could potentially cause problems for users who were using this undocumented parameter. Leaving the fourth and adding a fifth would get even more confusing if the appearance is that the fourth parameter was just added *and* served no purpose. So, we could relegate those VERY few who might've used that fourth parameter already to the read the changelog or suffer bucket, ornot. -Pollita -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 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); ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: str_ireplace vs. stri_replace
If your using an undocumented parameter, and that undocumented parameter changes what's the problem? The documentation doesn't say a word about a mystery undocumented parameter... I don't think we should be too concerned with someone using something they arguably shouldn't be. John -Original Message- From: Sara Golemon [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 30, 2003 5:39 PM To: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Re: str_ireplace vs. stri_replace +1 from me too, stri_replace sound like a function some users may +have implemented them selves and we could end up breaking their code by introducing it. exactly :). Only one complaint. Previously (including in 4.3.0) there already WAS a fourth (undocumented) parameter to str_replace. A boolean value which would allow the user to use an alternate search and replace method. True, this was undocumented, and was probably only included for developer debugging (Sascha? Can you enlighten us?). This alternate method has been removed (by virtue of being deprecated) and should produce wrong param count errors for users who include that fourth parameter currently (how many would even know of this?) so that they can fix their code. If we introduce a *new* fourth parametere (also boolean) which checks for case_sensitivity, this could potentially cause problems for users who were using this undocumented parameter. Leaving the fourth and adding a fifth would get even more confusing if the appearance is that the fourth parameter was just added *and* served no purpose. So, we could relegate those VERY few who might've used that fourth parameter already to the read the changelog or suffer bucket, ornot. -Pollita -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: str_ireplace vs. stri_replace
On Thu, 30 Jan 2003, Melvyn Sopacua wrote: MS MS Given this mess, and the fact that any php-coded stri_replace can be overloaded, K, strike this. The tricks used by mbstring to overload functions, cannot be applied in userland alone. Sorry for the noise. -- 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
Re: [PHP-DEV] Re: str_ireplace vs. stri_replace
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. Aggreed! The additional parameter solution is a pure developer friendly solution. The separate function is a user friendly solution. If we would like to make all happy then add the case-insensativity parameter to all str_ (not stri_) functions and add the additional function. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: str_ireplace vs. stri_replace
On Thu, 30 Jan 2003 17:11:53 -0500 Ilia A. [EMAIL PROTECTED] wrote:
On January 30, 2003 04:55 pm, Jon Parise wrote:
On Thu, Jan 30, 2003 at 01:44:27PM -0800, Sara Golemon wrote:
You're not the first to voice this opinion. *I* feel str_ireplace is
better as it follows the naming convention of module_function.
Others feel stri_replace is better as that follows eregi_replace's style.
I have no trouble going with whatever the majority feels is best.
Get rid of stri_replace() and/or str_ireplace() and just add a fourth
optional parameter to str_replace() to control case-sensitivity.
+1 from me too, stri_replace sound like a function some users may have
implemented them selves and we could end up breaking their code by
introducing it.
Although this is not my area of expertise, I would like to express my
negative opinion towards solving the problems with extra parameters.
Why?
1. Not all users will notice the extra parameter easily. Will take some
time.
2. If some users made their own function called stri_replace, this is
nothing that should be stopping from implementing it officially. In fact,
to fix it would be as easy as encapsuling the function declaration in
if(!function_exists('stri_replace')) {
function stri_replace($str = '') {
// ... user code
}
}
... which means acting on a centralized object - two lines of code after
an upgrade.
3. There is no reason to believe that this function was already used so
many times - as noted before, many have simply used regex. Look at this:
http://www.google.com/search?hl=enlr=ie=UTF-8oe=UTF-8q=stri_replace+-php.net
only 17 results. Of course, the use of this name might be much more, but
still - gives an idea of not such used user function.
Thus, my conclusion is that I doubt there is any gain of stability by
solving this issue with a parameter instead of an intuitive function.
--
Maxim Maletsky
[EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: str_ireplace vs. stri_replace
1. Not all users will notice the extra parameter easily. Will take some time. This modification will not appear until PHP 5 is released, by then this extra parameter (hopefully) will be well documented and people will be aware that it exists. Adding extra code, which virtually does the same thing IMHO is pointless and only creates a messy code that is difficult to maintain at a future point. 2. If some users made their own function called stri_replace, this is nothing that should be stopping from implementing it officially. In fact, to fix it would be as easy as encapsuling the function declaration in You are correct in the event of a user writing a new function, however consider what will happen if we are dealing with a old code, especially if it is no longer used just by the author but rather by a variety of other people not familiar with PHP code. The result is that after they or their ISPs upgrade to new PHP their scripts will stop working. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: str_ireplace vs. stri_replace
Well, if you're doing that, go ahead and change stristr() and strstr() too... And eregi() and ereg()... It should be done one way or another. Besides, wasn't one of the points in introducing this function that so many users were looking for it? Jon Parise [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... On Thu, Jan 30, 2003 at 01:44:27PM -0800, Sara Golemon wrote: You're not the first to voice this opinion. *I* feel str_ireplace is better as it follows the naming convention of module_function. Others feel stri_replace is better as that follows eregi_replace's style. I have no trouble going with whatever the majority feels is best. Get rid of stri_replace() and/or str_ireplace() and just add a fourth optional parameter to str_replace() to control case-sensitivity. -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: str_ireplace vs. stri_replace
On Thu, 30 Jan 2003, Sara Golemon wrote: Only one complaint. snip So, we could relegate those VERY few who might've used that fourth parameter already to the read the changelog or suffer bucket, ornot. I think this group of people is very small (less then 10 I assume), so I dont see it as much of a problem to 're'use the 4th parameter. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: str_ireplace vs. stri_replace
On Fri, 31 Jan 2003, Derick Rethans wrote: On Thu, 30 Jan 2003, Sara Golemon wrote: Only one complaint. snip So, we could relegate those VERY few who might've used that fourth parameter already to the read the changelog or suffer bucket, ornot. I think this group of people is very small (less then 10 I assume), so I dont see it as much of a problem to 're'use the 4th parameter. Let me add that even I have never used it. It's save to redeploy. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
