Edit report at https://bugs.php.net/bug.php?id=44794&edit=1

 ID:                 44794
 Comment by:         euromark at web dot de
 Reported by:        php dot net at mog dot se
 Summary:            Inconsistent order of argument for strtr compared to
                     str_replace
 Status:             Wont fix
 Type:               Bug
 Package:            Strings related
 PHP Version:        5.2.5
 Block user comment: N
 Private report:     N

 New Comment:

I can understand some of those legacy issues.
But I still think it is time to unify those functions from different times and 
different inheritance 
history. not only the params are different, also the naming scheme and the way 
they are called. some 
have CI argument, some an own function for it. so it is mainly not just about 
these two functions, but 
the str functions in general.

I put my ideas in a draft for Str.php here:
https://github.com/dereuromark/PHP

Let me know what you think. Maybe PHP6/7 can some day have such a Str class 
natively embedded (so that 
performance issues can pretty much be leveled).


Previous Comments:
------------------------------------------------------------------------
[2012-04-14 00:27:42] ras...@php.net

str_replace() is the way it was because it was written to be 
argument-compatible 
with preg_replace(). 

preg_replace(mixed $pattern , mixed $replacement , mixed $subject [, int $limit 
= -1 [, int &$count ]] )
str_replace (mixed $search , mixed $replace , mixed $subject [, int &$count ] )

since these two functions are extremely similar in functionality.

strtr() is quite different as it operates on individual characters along the 
lines of the low level strchr/strstr functions which are all haystack/needle to 
match the libc functions they mimic.

------------------------------------------------------------------------
[2012-04-13 23:45:08] euromark at web dot de

I agree that this just has to be fixed. It really is a nightmare. But just 
switching the order will most certainly create chaos (as mentioned).

Maybe we could introduce some static class which handles it for PHP6 and up:

    Php::str_str(string $haystack, mixed $needle [, bool $before_needle = 
false]);

    Php::str_split(string $string [, int $split_length = 1])

    Php::array_search(array $haystack, mixed $needle [, bool $strict = false ]);

=> Fix/Unify order, unify _ (strstr to str_str etc).

In general, wouldn't it be a good idea to create such a wrapper class in order 
to fix the issue right now? Has anyone 
started such a thing yet? Does it make sense? The execution time can usually be 
ignored (at this level the increase is 
probably only measurable with a looot of calls (> 10000).

If it will be fixed anytime in this century we can just drop the `Php::` prefix 
again. in the meantime we can overcome the 
legacy issue that really can be considered phps worse hangover.

------------------------------------------------------------------------
[2008-04-30 14:31:25] php dot net at mog dot se

Further response needed or i will need to submit a new bug report for this 
issue.

------------------------------------------------------------------------
[2008-04-22 14:24:56] php dot net at mog dot se

iliaa, yes, i already stated that in my description. That's why i suggested 
adding a new function which is not inconsistent, and then the old function 
would be kept for backwards compatibility only.

Does the PHP team not care about API consistency or why was the bug closed with 
so little discussion?

If an acceptable solution can be agreed upon i would be happy to write a patch 
myself.

Regards,
Morgan

------------------------------------------------------------------------
[2008-04-22 12:40:06] il...@php.net

Any changes here will introduce massive BC breaks.

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    https://bugs.php.net/bug.php?id=44794


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=44794&edit=1

Reply via email to