by Michael S. Kaplan, published on 2007/04/12 07:31 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/04/12/2098486.aspx
Well, here is my logic.
The System.String class has many members that support the current culture by default, and other cultures/comparison types by parameter.
You know, like string.Compare and so on.
But there is one member that does not have this behavior, at all. Either by default or via parameter modification -- string.Replace.
Which is really unfortunate given that the "find" support in string.IndexOf makes it so easy to expect that if you can find a string using some cultural/linguistic sensitivities that you'd be able to replace using those same cultural/linguistic sensitivities, right?
Though the fact that this does not work may be in part due to an omission I mentioned previously in in On being consistently consistent, while still managing to be dead wrong:
...in the case of FindNLSString there was a pcchFound parameter that would let the caller know that what was found was also of zero length so that a sensible and consistent check on that return of 0 would keep one from an AV. With the bonus that being that the check made sense in the non-corner cases, too. And not just for the sake of consistency but for the sake of returning correct results.
Looking back to managed code, .NET doesn't have this feature, and there is in fact no easy way to emulate it in linguistically appropriate string comparisons; this was the reason that FindNLSString was added to Vista in the first place!
In fact, it was in the initial design planning for FindNLSString, back when we were calling it plain old FindString, that Tarek (another dev on our team who I have mentioned before) pointed out that without the functionality that the pcchFound parameter provided, there was no good way to add replace logic via FindNLSString.
(I find Tarek's cool contribution to FindNLSString to be quite ironic given that he owns a lot of the .NET Framework side of things, and the .NET Framework does not yet have this functionality. It causes lots of weirdness that keeps the System.String.Replace method from working consistently with System.String.Compare in many cases!)
So there it is....
What with all the green bits/red bits silliness, it will be a while before this could be potentially addressed with another overload. And then even longer before a string.Replace overload that made use of the new functionality could be planned out.
Since it is just doing a binary operation, clearly string.Replace does not support "international" the way all of the other methods do, by default or otherwise.
And thus by the converse theory of logic international support does not cover Replace.
Which could easily be reworded (by a blog author who was willing to go to great lengths to try to take advantage of a pun!) international support is irREPLACEable.
How'd I do? :-)
Ok, seriously. This would make a cool set of features in a future version, I think. Even if the string.Replace method couldn't be made consistent with the other string members involving collation support in the default case for fear of backward compatibility breaks....
This post brought to you by я (U+044f, a.k.a. CYRILLIC SMALL LETTER YA)