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] [email protected]
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] [email protected]
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
