Решение проблемы NSInteger <-> NSNumber

Я написал большое приложение для iPhone в социальной сети, и одна из самых больших проблем, с которыми я столкнулся, заключается в том, что NSInteger (и все другие NS-не-объектные типы) не являются первоклассными гражданами. Эта проблема проистекает из того факта, что, очевидно, они не имеют представления для нулевого значения.

Это создает две основные проблемы:

1. Тонны накладных расходов и непрозрачности для преобразования в NSNumber и из него при сохранении / извлечении из коллекции.
2. Не может представлять ноль. Часто я хочу иметь возможность представлять «неустановленное» значение.

Один из способов решить эту проблему - постоянно использовать NSNumber, но это сильно сбивает с толку. В объекте модели User у меня было бы около 20 различных NSNumber, и было бы непросто определить, является ли каждый из них числами с плавающей запятой, целым числом, логическим значением и т. Д.

Итак, вот мои мысли о возможных решениях и плюсах / минусах. Я не особо заинтересован ни в одном из них, поэтому подумал, что попрошу отзывов и / или альтернативных решений этой проблемы.

1. Продолжайте использовать типы NSInteger и просто используйте NSIntegerMax для представления nil.
   PRO - Меньше накладных расходов на память
   PRO - Четкий ввод
   CON - NSIntegerMax на самом деле не равен нулю. Если программисты неосторожны или не знают этого соглашения, недопустимые значения могут просочиться в слой отображения.
   CON - Невозможно сохранить их в коллекции без преобразования в и из
   
   
2. Используйте NSNumber и обозначьте типы, используя венгерскую нотацию (например, NSNumber fHeight, NSNumber iAge)
   PRO - Первоклассный граждане
   PRO - Проблема не решена
   CON - Повышенные накладные расходы на память
   CON - Не проверять тип компилятора
   CON - Венгерская нотация спорна
   
   
3. Пишу мои собственные первоклассные примитивные типы объектов (подумайте о Java http://developer.android.com/reference/java/lang/Integer.html )
   PRO - Первоклассные граждане
   PRO - Проблема не решена
   PRO - Сохраняется проверка типа компилятором
   PRO - Объекты будут проще, чем NSNumber. Внутреннее хранилище зависит от типа данных.
   CON - Повышенные накладные расходы на память
   CON - Немного жертвуют переносимостью кода и совместимостью
   

Ищете убедительный аргумент в пользу одного из этих методов или одного. не думал, есть ли он у вас.

ОБНОВЛЕНИЕ

Я пошел дальше и начал проект с открытым исходным кодом (Apache 2.0), в который я буду использовать несколько наших внутренних классов, когда у меня будет время. В настоящее время он включает объектные оболочки для некоторых наиболее распространенных нативных типов данных (BOOL, CGFloat, NSInteger, NSUInteger). Мы выбрали это, потому что он обновляет эти типы данных до первоклассных граждан со строгой типизацией. Возможно, вы не согласны с таким подходом, но он сработал для нас, поэтому не стесняйтесь использовать его, если хотите.

Я добавляю другие классы, для которых мы нашли применение, включая дисковый кэш LRU, объект «Pair», пул освобождения малой памяти и т. Д.

Наслаждайтесь github - Zoosk / ZSFoundation