Edit report at https://bugs.php.net/bug.php?id=44794&edit=1
ID: 44794
Updated by: ras...@php.net
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:
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.
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2008-04-21 17:56:32] php dot net at mog dot se
Description:
------------
The similar but different string replacement functions str_replace strtr() have
an inconsistent order of arguments, in strtr() $subject is the first argument
and in str_replace it is the last.
strtr($subject, $search, $replace)
str_replace($from, $to, $subject)
There is no logic in this behaviour so every time i use these functions i have
to look them up to find out which is which.
There is no backwards compatible way to fix this as all arguments can be
strings, so new API functions would be needed while keeping strtr and
str_replace as is.
The PHP API desparatley needs a naming convention and this IMO is one of it's
worst examples.
Expected result:
----------------
Without an obvious fix i can only offer my ideas on how to fix this:
#1
Adding a str_translate($from, $to, $subject) method would be possible, assuming
that this order is consistent with the rest of PHP's API
#2
A solution which is very logical & consistent would be if strings acted like
objects, then $subject->replace($from, $to) and $subject->translate($from, $to)
would be possible.
My guess would be that treating strings as objects would not be a clean
implementation, but perhaps an OO version of string is possible in SPL.
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=44794&edit=1
