StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POSolving the NSInteger <-> NSNumber problem
text
Body
copied!<p>I've written a large social networking iPhone application, and one of the biggest issues I run into is the fact that NSInteger (and all the other NS-non-object types) are not first class citizens. This problem stems from the fact that, obviously, they have no representation for a nil value.</p> <p>This creates two main problems:</p> <ol> <li>Tons of overhead and opaqueness to convert to and from NSNumber when storing/retrieving from a collection.</li> <li>Can't represent nil. Oftentimes, I want to be able to represent an "unset" value.</li> </ol> <p>One way to solve this is to use NSNumber all the time, but that gets extremely confusing. In a User model object, I would have about 20 different NSNumbers, and no easy way to tell if each one is a float, integer, bool, etc.</p> <p>So here are my thoughts for potential solutions and the pros/cons. I'm not really sold on any of them, so I thought I'd ask for feedback and/or alternative solutions to this problem.</p> <ol> <li><strong>Continue to use NSInteger types, and just use NSIntegerMax to represent nil.</strong><br/> PRO - Less memory overhead<br/> PRO - Clear typing<br/> CON - NSIntegerMax is not really nil. If programmers aren't careful or don't know this convention, invalid values could leak into the display layer.<br/> CON - Can't store them in a collection without conversions in and out<br/><br/></li> <li><strong>Use NSNumber and designate types using hungarian notation (eg NSNumber fHeight, NSNumber iAge)</strong><br/> PRO - First-class citizens<br/> PRO - Nil problem solved<br/> CON - Increased memory overhead<br/> CON - Lose compiler type checking<br/> CON - Hungarian notation is contentious<br/><br/></li> <li><strong>Write my own first-class primitive object types (think Java <a href="http://developer.android.com/reference/java/lang/Integer.html" rel="nofollow">http://developer.android.com/reference/java/lang/Integer.html</a>)</strong><br/> PRO - First-class citizens<br/> PRO - Nil problem solved<br/> PRO - Keeps compiler type checking<br/> PRO - Objects will be simpler than NSNumber. Internal storage will specific to data type.<br/> CON - Increased memory overhead<br/> CON - Sacrifices a bit of code portability and compatibility<br/></li> </ol> <p>Looking for a convincing argument in favor of one of these techniques, or one I haven't thought of if you've got one.</p> <hr> <p><strong>UPDATE</strong></p> <p>I've gone ahead and started an open source project (Apache 2.0), into which I'll be pulling a number of our internal classes as I have time. It currently includes object wrappers for some of the more common native data types (BOOL, CGFloat, NSInteger, NSUInteger). We chose to do this because it upgrades these data types to first class citizens with strict typing. Maybe you disagree with this approach, but it has worked well for us, so feel free to use it if you want.</p> <p>I'm adding other classes we've found uses for, including a disk-backed LRU cache, a "Pair" object, a low memory release pool, etc.</p> <p>Enjoy <a href="https://github.com/Zoosk/ZSFoundation" rel="nofollow">github - Zoosk/ZSFoundation</a></p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload