Add -containsString: and -containsString:options: methods
| Originator: | quinntaylor |
|
| Number: | rdar://7710615 |
Date Originated: | 2010-03-02 |
| Status: | Open |
Resolved: | |
| Product: | NSString |
Product Version: | |
| Classification: | Enhancement |
Reproducible: | Not Applicable |
I'd love to see -containsString: (and -containsString:options:) officially added to NSString. People not familiar with Cocoa are often stymied when they can't find such a method, since they don't know to look for NSRange-related functions, or understand checking range.location != NSNotFound.
I understand the über-conservative approach we generally take with adding new API, but it would seem this should have been around since 10.0. Despite the fact that you can already accomplish this with a few more lines of code, such overlap isn't without precedent. For example, NSSet has both -member: and -containsObject: and both are useful. Sometimes you just need a boolean value, not all the extra fluff.
Developers often write their own -containsString: method to get around this shortcoming, added via categories. When this happens in reusable code (third-party libraries or frameworks), conflicts and uncertainty arise, particularly when such methods respond differently and/or not as -rangeOfString:options: does.
RELATED: <rdar://6883210> claims that NSString responds to an undocumented -containsString: method, although it issues a warning at compile time, but I can't reproduce this behavior on Snow Leopard. I'm wondering whether it's possibly a category conflict causing undefined results.
Duplicates
Comments
aglvcGVucmFkYXJyDQsSBVJhZGFyGKuMCgw
Please note:
Reports posted here will not necessarily be seen by Apple.
All problems should be submitted at bugreport.apple.com before they are posted here.
Please only post information for Radars that you have filed yourself, and please do
not include Apple confidential information in your posts. Thank you!