Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

deprecate stringByReplacing:with: #1821

Merged
merged 1 commit into from Apr 17, 2014
Merged

deprecate stringByReplacing:with: #1821

merged 1 commit into from Apr 17, 2014

Conversation

skurfer
Copy link
Member

@skurfer skurfer commented Apr 12, 2014

As requested by @tiennou.

a similar method has been available from Apple since 10.5
@pjrobertson
Copy link
Member

@pjrobertson pjrobertson commented Apr 17, 2014

Was just about to merge this, then I noticed that the two methods aren't exactly equivalent. According to the comments in NSString.h:

/* Replace all occurrences of the target string in the specified range with replacement. Specified compare options are used for matching target. If NSRegularExpressionSearch is specified, the replacement is treated as a template, as in the corresponding NSRegularExpression methods, and no other options can apply except NSCaseInsensitiveSearch and NSAnchoredSearch.
*/
- (NSString *)stringByReplacingOccurrencesOfString:(NSString *)target withString:(NSString *)replacement options:(NSStringCompareOptions)options range:(NSRange)searchRange NS_AVAILABLE(10_5, 2_0);

/* Replace all occurrences of the target string with replacement. Invokes the above method with 0 options and range of the whole string.
*/
- (NSString *)stringByReplacingOccurrencesOfString:(NSString *)target withString:(NSString *)replacement NS_AVAILABLE(10_5, 2_0);

I.e. the difference is that the current method uses NSLiteralSearch as options, but the new one doesn't. A bit of googling gives:

“Literal” when applied to string comparison means that various Unicode decomposition rules are not applied and Unicode characters are individually compared. So, for instance, “Ö” represented as the composed character sequence “O” and umlaut would not compare equal to “Ö” represented as one Unicode character.

Not sure if we want to be literal, but... hmmm :/ @tiennou ? :)

@tiennou
Copy link
Member

@tiennou tiennou commented Apr 17, 2014

Good catch. Frankly, I don't see a reason to use a literal search (except maybe performance, but it's not like it's called in a loop anywhere) because it can causes problems if you're not aware of the current canonical form of your strings.

pjrobertson added a commit that referenced this issue Apr 17, 2014
deprecate stringByReplacing:with:
@pjrobertson pjrobertson merged commit 7be56f6 into master Apr 17, 2014
1 check passed
@pjrobertson pjrobertson deleted the replacestring branch Apr 17, 2014
@pjrobertson
Copy link
Member

@pjrobertson pjrobertson commented Apr 17, 2014

Yeah I couldn't really think of a reason why, seems to make more sense not to do a literal search.

Merged

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants