De : Nikita Popov [mailto:nikita....@gmail.com]
>
> str_replace is a simple function for string replacement. It has some (imho
> also unnecessary)
> extra gimmicks to implicitly do a foreach() loop during the replacement. This
> is still relatively
> simple API-wise. But if I see this (taken from the tests) as the search &
> replacement values...
> $search=array('[?]',array('(?)','d','e'),'a','R');
> $repl=array(
> array('ap(?)z[?]',"b[?](?)v",null,37,"[?]n[?]"),
> array('a',array('b',null)),
> array('k(?)j[?]')
>);
> ... I have a pretty hard time figuring out what this is actually supposed to
> do.
This is not a real use case, this is edge-case testing !
> At this point str_replace is working on arbitrarily-nested arrays and also
> has four options to control its behavior.
> Imho this is just too much complexity for a relatively minor use case.
Let's take this one by one :
First, this all started with two feature requests for this feature. I then
asked on the list what people thought about it and the return what 100%
positive.
So, I started a first implementation to just allow cyclic replace with a loop
behavior. At this time, an empty replace array was considered as an empty
string, with no warning.
Then R. Quadling complained that we should provide a way to control what
happens when we arrive at the end of the replace array. I hadn't done it
because I didn't want to change the API. We finally agreed on an additional
options arg with five possible values. I don't like the additional arg but I
accept it because : 1. It is added as last arg and most people will never see
it, and 2. it can be useful if we need additional flags in the future. For
instance, if we had defined this arg at the beginning, it could have handled
case-sensitivity, which wouldn't have been worse than writing a sister
function. I even think now to define a STR_REPLACE_CASE_INSENSITIVE flag as an
alternative to str_ireplace(). This would provide all str_[i]replace features
in a single function (don't worry, the BC break is too huge to deprecate
str_ireplace()).
Then, you asked for an error on empty replace array. I added that.
Then, it came to my mind that, if we accept the combination of (string search,
array replace).we must be consistent and, as we already accept (array search),
we must also accept ((array of arrays) replace). The extension to
arbitrarily-nested arrays is not essential but it didn't cost much and allowed
for a cleaner multi-layered C design. Honestly, I hope we keep supporting it
because removing it would add complexity in the code but I am not sure we must
document recursion support beyond 1 level for search / 2 levels for replace
(even if side notes will quickly document it). I agree that supporting (array
search) may be a wrong decision (more complexity, just for performance
reasons), but it was made a long time ago and a lot of people use it now...
I then thought that, as I had (quite useless) recursion for search/replace, the
least I could do was to provide the same for subject because, here, it is
really valuable. It is a quite natural use case to want converting every
strings in an arbitrarily-nested array and I imagine people will quickly use
this. As before, it also brings a cleaner design in C code.
To summarize, I started with a rather simple feature request and was then
pushed by external wishes. About added complexity in code, the summary is about
100 lines of new (cruelly missing) comments, 100 lines added, and 130 lines
modified. The rest comes from additional tests (which could be simpler, ok,
ok). If you consider that the design is now simpler to understand, this is not
so bad.
So, all in all, I think that the whole balance is positive, even if adding an
argument is never wanted.
That said, I am always open to discussion and will never tell you that it must
remain so because I have spent *endless* hours coding it :). Finally, a vote
will take place starting January,20, which will probably require 2/3 of voices
(not sure because BC break is very minimal, but we are adding an argument...).
Sorry for posting in the same thread. I will post a new [RFC]-prefixed message.
If you want your arguments to be more visible to newcomers, you may post them
in the PR. If you do it, I will then post my reply.
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
