Bug #44794 [Com]: Inconsistent order of argument for strtr compared to str_replace

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 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. Previous Comments: ------------------------------------------------------------------------ [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] iliaa@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