Что мы обошлись бы без ПУСТОГО УКАЗАТЕЛЯ?
Я когда-то считал, что наличие nullable типов является абсолютным злом. Я полагаю, что это было в статье, написанной самым человеком, который создал их (в Ada?) Я полагаю, что это - статья
Так или иначе, поэтому что, если по умолчанию язык как C# использовал не допускающие NULL-значения типы? Как Вы заменили бы некоторые общие идиомы в C# или Ruby или каком-либо другом общем языке где null допустимое значение?
7 ответов
Вместо прямого объявления, что типы, допускающие значение NULL являются злом, я бы сказал: большинство языков прививают допустимость значений NULL целым типам, в то время как эти два понятия действительно должны быть ортогональными .
Например, все непримитивные типы Java (и все ссылочные типы C #) допускают значение NULL. Почему? Мы можем двигаться вперед и назад, но в конечном итоге я уверен, что ответ сводится к тому, что «это было легко». В языке Java нет ничего такого, что требовало бы повсеместной допустимости значений NULL. Ссылки на C ++ являются прекрасным примером того, как изгнать нули на уровне компилятора. Конечно, C ++ имеет гораздо более уродливый синтаксис, который Java явно пыталась сократить, поэтому некоторые хорошие функции оказались на грани отказа вместе с плохими.
Типы значений, допускающие значение NULL в C # 2.0 предлагал шаг в правильном направлении - отделение допустимости значений NULL от семантики несвязанных типов или, что еще хуже, деталей реализации CLR - но по-прежнему отсутствует способ сделать противоположное со ссылочными типами. (Контракты кода - это здорово и все такое, но они не встроены в систему типов, как мы здесь обсуждаем.)
Множество функциональных или других малоизвестных языков получили эти концепции «прямо» с самого начала ... но если бы они были широко распространены, у нас бы не было этого обсуждения ...
Чтобы ответить на ваш вопрос: запретить нули в современном языке оптом было бы так же глупо, как и так называемая «ошибка на миллиард долларов». " Существуют допустимые программные конструкции, в которых хорошо иметь нули: необязательные параметры, любые расчеты по умолчанию / откат, когда оператор объединения приводит к сжатому коду, взаимодействие с реляционными базами данных и т. Д. Принуждение себя к использованию контрольных значений, NaN и т. Д. Будет «лекарство» гораздо хуже, чем болезнь.
Тем не менее, я предварительно согласен с мнением , выраженным в цитате, при условии, что я могу уточнить, исходя из моего собственного опыта:
- # ситуаций, в которых желательны нули, меньше чем большинство людей думает
- , когда вы вводите нули в библиотеку или кодовый путь, избавиться от них намного труднее, чем добавить их. (так что не позволяйте младшим программистам делать это по прихоти!)
- количество ошибок, допускающих значение NULL, масштабируется с переменным временем жизни
- , что соответствует № 3: ранний сбой
Я думаю, вы имеете в виду этот разговор: "Нулевые ссылки: The billion dollar mistake"
Tcl - это язык, в котором не только отсутствует концепция null, но и сама концепция null противоречит ядру языка. В tcl мы говорим: «все является строкой». На самом деле это означает, что tcl имеет строгую семантику значений (которая просто используется по умолчанию для строк).
Так что же программисты tcl используют для обозначения «без данных»? В основном это пустая строка. В некоторых случаях, когда пустая строка может представлять данные, обычно используется одно из следующих значений:
В любом случае использовать пустую строку - в большинстве случаев это не имеет значения для конечного пользователя.
Используйте значение, которое, как вы знаете, не будет существовать в потоке данных - например, строка
«_ NULL _»или число9999999или мой любимый байт NUL» \ 0 ".Используйте структуру данных, обернутую вокруг значения - самый простой - это список (то, что в других языках называется массивами). Список из одного элемента означает, что значение существует, нулевой элемент означает ноль.
Проверка существования переменной -
[существует информация имя_переменной].
Интересно отметить, что Tcl - не единственный язык со строгой семантикой значений. C также имеет строгую семантику значений, но семантика значений по умолчанию оказывается целыми числами, а не строками.
О, чуть не забыл еще один:
Некоторые библиотеки используют вариант числа 2, который позволяет пользователю указать, какой заполнитель для «нет данных». По сути, он позволяет вам указать значение по умолчанию (а если вы этого не сделаете, то обычно по умолчанию используется пустая строка).
Мы используем либо
Дискриминаторы. Дополнительный атрибут, флаг или индикатор, который говорит, что значение является "нулевым" и должно быть проигнорировано.
Доменно-специфические нули. Конкретное значение - в пределах допустимой области - которое интерпретируется как "игнорировать это значение". Например, номер социального страхования 999-99-9999 может быть специфическим для домена нулевым значением, которое говорит, что SSN либо неизвестен, либо неприменим.
Мы бы создали всевозможные странные конструкции, чтобы передать сообщение о том, что объект «недействителен» или «не существует», как показано в других ответах. Сообщение, которое null может передать очень хорошо.
- Шаблон Нулевой объект имеет свои недостатки, как я объяснил здесь .
- Нулевые значения для домена. Это заставляет вас проверять магические числа , что плохо .
- Оболочки коллекций, где пустая коллекция означает «нет значения». Обертки , допускающие значение NULL, были бы лучше, но это не сильно отличается от проверки на
nullили использования шаблона Null Object.
Лично я бы написал некоторый препроцессор C #, который позволяет мне использовать null . Затем это будет отображаться на некоторый динамический объект, который выдает исключение NullReferenceException всякий раз, когда для него вызывается метод.
Еще в 1965 году пустые ссылки могли казаться ошибкой. Но в настоящее время со всеми видами инструментов анализа кода, которые предупреждают нас о нулевых ссылках, нам не о чем сильно беспокоиться. С точки зрения программирования null - очень ценное ключевое слово.
Мы бы использовали типов опций для (очень) немногих мест, где разрешение нулевого значения действительно желательно, и у нас было бы намного меньше неясных ошибок, поскольку любые Ссылка на объект будет гарантированно указывать на действительный экземпляр соответствующего типа.
Вы можете принять простое правило: все переменные инициализируются (по умолчанию, это можно переопределить) неизменным значением, определяемым классом переменной. Для скаляров это обычно будет некоторая форма нуля. Для ссылок каждый класс будет определять его «нулевое» значение, и ссылки будут инициализированы указателем на это значение.
Это была бы реализация шаблона NullObject для всего языка: http://en.wikipedia.org/wiki/Null_Object_pattern Таким образом, он на самом деле не избавляется от нулевых объектов, он просто не дает им быть особыми случаями, которые должны обрабатываться как таковые.