php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #44794 Inconsistent order of argument for strtr compared to str_replace
Submitted: 2008-04-21 17:56 UTC Modified: 2012-04-14 16:39 UTC
Votes:4
Avg. Score:4.0 ± 1.0
Reproduced:4 of 4 (100.0%)
Same Version:1 (25.0%)
Same OS:1 (25.0%)
From: php dot net at mog dot se Assigned:
Status: Wont fix Package: Strings related
PHP Version: 5.2.5 OS:
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: php dot net at mog dot se
New email:
PHP Version: OS:

 

 [2008-04-21 17:56 UTC] 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.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-04-22 12:40 UTC] iliaa@php.net 
Any changes here will introduce massive BC breaks.
 [2008-04-22 14:24 UTC] 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-30 14:31 UTC] php dot net at mog dot se 
Further response needed or i will need to submit a new bug report for this issue.
 [2012-04-13 23:45 UTC] 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.
 [2012-04-14 00:27 UTC] rasmus@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-14 14:08 UTC] euromark at web dot de 
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).
 [2012-04-14 16:39 UTC] rasmus@php.net 
That can easily be done in userspace and since we can't remove the core functions 
for BC reason I don't really see how it helps to have yet another set of aliases 
in the core.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Tue May 13 10:01:27 2025 UTC