5 ms·
`[a compare:b]` returns 0 both if they are equal and if a is nil.
by judofyr 14y ago
`[a compare:b]` returns 0 both if they are equal and if a is nil.
- tyler-dodge 14y agoTrue, although none of the other return values make that much sense with nil either.
- ajanuary 14y agoCheers for the counter-example. I can't think of a compare method in the Objective-C core lib (the biggest nil-swallowing lib I know of). Does anyone know of one? Would be interesting to see how it's handled and if it causes issues. You could return an enum, which would allow you to use non-obvious values (Lower = 1, Equal = 2, Higher = 3), though this would make it a bit of a pain to interface with C-style libs. Obviously the presence of a work-around doesn't mean nil-swallowing is a good idea, but rather cements the idea that library authors need to put in extra effort to make sure nil receivers are handled appropriately.
- judofyr 14y ago> I can't think of a compare method in the Objective-C core lib (the biggest nil-swallowing lib I know of). Does anyone know of one? Would be interesting to see how it's handled and if it causes issues. Maybe I misunderstood you, but there is plenty of compare:'s in Cocoa: http://cl.ly/image/1a112f1B1W1g http://cl.ly/image/1a112f1B1W1g. They all return an enum that's either -1, 0 or 1.
- chc 14y agojudofyr's code is actually valid. Most "value" classes have compare: — NSString, NSDate, NSNumber, etc.
- Groxx 14y agoI'd argue this is correct. If a is nil, it's not comparable. The alternative would be to throw an exception, which is pretty simple to emulate by checking. Also, nils aren't allowed in the collection classes, so sorting with compare: will simply never encounter this case.