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
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
2011/6/20 Derick Rethans derick@php.net
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."This could be one possible implementation. My implementation doesn't
change the old behaviour ofstrtr(). 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
Em Mon, 20 Jun 2011 12:32:30 +0100, Robert Eisele robert@xarg.org
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
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 glopes@nebm.ist.utl.pt
Em Mon, 20 Jun 2011 12:32:30 +0100, Robert Eisele robert@xarg.org
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
Hi!
Stas,
Why should it be a BC break? Empty strings are not considered, in any mode
or what feature ofstrtr()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
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
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.
I agree that this is not a good thing then.
cheers,
Derick
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.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/
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
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 sayIt 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/
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.
On Wed, Jun 22, 2011 at 3:30 AM, Sanford Whiteman
swhitemanlistens-software@cypressintegrated.com wrote:
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 enteringstrtr()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/