# Changed behaviour for strtr() - Thread: https://externals.io/message/53381 - Original archive: https://news-web.php.net/php.internals/53381 - Started by Robert Eisele on 2011-06-20T11:16:22+00:00 - Messages: 13 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #53381 — Robert Eisele — 2011-06-20T11:16:22+00:00 URL: https://externals.io/message/53381#53381 Here is the next one. I think it's quite intuitive to use `strtr()` to remove single characters of a string, too, instead of using many str_replace($str, $chr, ""). I'd glad to see this change also in 5.4. Additionally, I've removed the lookup-table generation as gcc doesn't optimize this away. Robert --- ## #53382 — Derick Rethans — 2011-06-20T11:20:05+00:00 URL: https://externals.io/message/53381#53382 · In reply to: #53381 > Here is the next one. > > I think it's quite intuitive to use `strtr()` to remove single characters of a > string, too, instead of using many str_replace($str, $chr, ""). I'd glad to > see this change also in 5.4. Do you mean that (the currently documented): "If from and to have different lengths, the extra characters in the longer of the two are ignored. The length of str will be the same as the return value's." would then change into: "If from and to have different lengths, the extra characters in the longer of the two are assumed to be the empty string, thus removing those characters. The length of str will be the same as the return value's unless the from and to have a different length." cheers, Derick --- ## #53385 — Robert Eisele — 2011-06-20T11:32:30+00:00 URL: https://externals.io/message/53381#53385 · In reply to: #53382 2011/6/20 Derick Rethans > > > > […] > of a > > […] > to > > […] > > Do you mean that (the currently documented): > > "If from and to have different lengths, the extra characters in the > longer of the two are ignored. The length of str will be the same as the > return value's." > > would then change into: > > "If from and to have different lengths, the extra characters in the > longer of the two are assumed to be the empty string, thus > removing those characters. The length of str will be the same as > the return value's unless the from and to have a different length." > > This could be one possible implementation. My implementation doesn't change the old behaviour of `strtr()`. I simply used the length of the "smaller" value to indicate what mode should get used; if the length is zero, all characters get removed like this: $demise = strtr("passion", "os", ""); which results in "pain" > cheers, > Derick > Robert --- ## #53432 — Stas Malyshev — 2011-06-20T16:58:16+00:00 URL: https://externals.io/message/53381#53432 · In reply to: #53381 Hi! > Here is the next one. > > I think it's quite intuitive to use `strtr()` to remove single characters of a > string, too, instead of using many str_replace($str, $chr, ""). I'd glad to > see this change also in 5.4. This is a BC break, if I understand it correctly, so I don't think it is a good idea. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #53434 — Gustavo Lopes — 2011-06-20T17:15:15+00:00 URL: https://externals.io/message/53381#53434 · In reply to: #53385 Em Mon, 20 Jun 2011 12:32:30 +0100, Robert Eisele escreveu: > > $demise = strtr("passion", "os", ""); > This is a very bad idea for several reasons: - strtr already does this with: $demise = strtr("passion", array("o" => "", "s" => "")); - it's a BC break - adds a *third* operation mode to strtr, which (IMO unwisely) already provides two completely different algorithms. -- Gustavo Lopes --- ## #53440 — Robert Eisele — 2011-06-20T17:56:33+00:00 URL: https://externals.io/message/53381#53440 · In reply to: #53434 Stas, Why should it be a BC break? Empty strings are not considered, in any mode or what feature of `strtr()` did I miss? Gustavo, does you not constradict yourself, when you say it's already available in the one mode and in the other it shouldn't be? What about the intuitive and nosy developers that expects this feature in both modes, the array-mode and the string-mode? And yes, it would be a third completely different algorithm. But every algorithm is specialized for one use-case, and I think we shouldn't decide such things based on the number of algorithms used; especially for such a basic function where the result should be calculated as fast as possible, no matter which algorithm led to the final result. You also call it a BC break, what did I missed? If we agree with this feature, we could, of course, search for a different syntax; but it was the most obvious. Robert 2011/6/20 Gustavo Lopes > Em Mon, 20 Jun 2011 12:32:30 +0100, Robert Eisele > escreveu: > > > > […] > This is a very bad idea for several reasons: > - strtr already does this with: > $demise = strtr("passion", array("o" => "", "s" => "")); > - it's a BC break > - adds a *third* operation mode to strtr, which (IMO unwisely) already > provides two completely different algorithms. > > -- > Gustavo Lopes --- ## #53441 — Stas Malyshev — 2011-06-20T18:08:52+00:00 URL: https://externals.io/message/53381#53441 · In reply to: #53440 Hi! > Stas, > Why should it be a BC break? Empty strings are not considered, in any mode > or what feature of `strtr()` did I miss? Because now strtr("passion", "os", "") returns different result. Combined with the fact that you already can do it with array syntax, I don't really see a point. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #53471 — Derick Rethans — 2011-06-21T10:55:30+00:00 URL: https://externals.io/message/53381#53471 · In reply to: #53432 > > […] > > This is a BC break, if I understand it correctly, so I don't think it is a > good idea. I agree that this is not a good thing then. cheers, Derick --- ## #53497 — Jordi Boggiano — 2011-06-22T00:14:06+00:00 URL: https://externals.io/message/53381#53497 · In reply to: #53471 > > > > […] > > I agree that this is not a good thing then. Right now strtr('anything', 'anything', '') === 'anything', which means that anyone relying on this behavior is doing something strange and dumb imo, doing a function call for nothing. We could maybe say that strtr('anything', 'anything', null) maps all letters to an empty string? That should take care of the user-based inputs for BC reasons, while still allowing `strtr()` to be used for this "strip letter x and y" use case. Anyway I'm not gonna fight one way or the other, it's a detail, but I don't think the BC concern is as big as it's presented. Cheers -- Jordi Boggiano @seldaek :: http://seld.be/ --- ## #53498 — Stas Malyshev — 2011-06-22T00:22:38+00:00 URL: https://externals.io/message/53381#53498 · In reply to: #53497 Hi! > Right now strtr('anything', 'anything', '') === 'anything', which > means that anyone relying on this behavior is doing something strange > and dumb imo, doing a function call for nothing. We could maybe say It does not matter if you approve or disapprove how people write their code - we can't break BC unless there's a VERY good reason. You never know in which situation with which combination of inputs which application may end up using this sequence of parameters and how changing it may break it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #53499 — Jordi Boggiano — 2011-06-22T00:36:54+00:00 URL: https://externals.io/message/53381#53499 · In reply to: #53498 > > […] > > It does not matter if you approve or disapprove how people write their code > - we can't break BC unless there's a VERY good reason. You never know in > which situation with which combination of inputs which application may end > up using this sequence of parameters and how changing it may break it. Of course it's not just a matter of taste, but the null case imo really is not likely to happen by accident, and there is no valid use case. Anyways.. Case closed I suppose. Cheers -- Jordi Boggiano @seldaek :: http://seld.be/ --- ## #53500 — Sanford Whiteman — 2011-06-22T01:30:24+00:00 URL: https://externals.io/message/53381#53500 · In reply to: #53497 > Right now strtr('anything', 'anything', '') === 'anything', which > means that anyone relying on this behavior is doing something strange > and dumb imo, doing a function call for nothing. How is relying on by-design behavior that turns the call into a no-op (instead of wrapping the call in an empty() check or whatever) dumb? Is there some performance hit for entering `strtr()` that makes this true? -- S. --- ## #53503 — Jordi Boggiano — 2011-06-22T07:44:16+00:00 URL: https://externals.io/message/53381#53503 · In reply to: #53500 On Wed, Jun 22, 2011 at 3:30 AM, Sanford Whiteman wrote: > > […] > > How  is relying on by-design behavior that turns the call into a no-op > (instead  of  wrapping the call in an empty() check or whatever) dumb? > Is  there  some  performance  hit for entering `strtr()` that makes this > true? Well, all I was saying was that you'd never hardcode such thing, it could happen with dynamic user input, but in that case you'd have a string, and not null. Anyway as always with PHP there's probably a couple guys somewhere in the world that did it in a way that BC will break for them. I just think it's awkward to deny this feature for a possible edge case in which BC would be broken, while in other instances BC is broken in bigger ways, sometimes by accident, and sometimes in minor versions too. Cheers -- Jordi Boggiano @seldaek :: http://seld.be/