The last post about isEqual: vs isEqualToString: included some timings I made to test the performance of those two calls, along with
compare:. That posting mentioned going down a rabbit hole, verifying commonly held beliefs of about
isEqualToString:. The other rabbit hole I went down related to the performance tuning. A couple of commenters on the post asked some good questions relating to the timings, especially about literal strings.
_TL;DR: When to use
isEqualToString:? There’s no meaningful performance difference between the two. For convenience use
isEqual:. For a modicum of type safety use
isEqualToString:, but it’s not as safe as you might believe. If you have unicode strings with different normalizations, use
compare:. Be careful if
nils are involved.
We have a lot of very convenient, very powerful methods at our disposal such as
[NSData dataWithContentsOfFile:]. This method goes to the file system, opens the file, reads in all the bytes, closes the file, packs the bytes into an
NSData, and returns it back to us. It replaces a loop and several other lines of code into one convenient package. If it can’t do the work, it returns
nil. That’s pretty simple.
Last night at the Highgroove Studios office, we held the March edition of Hack Night, our monthly social coding gathering. We focused on starting, polishing, and/or discussing open source projects ranging from the super useful to the super silly (beer is always provided at our hack nights…)
You might want to check out Part 1 if you haven’t already seen the new
NSDictionary literal syntax, and using square brackets to dig into collections.