Почему в .NET существует null?

Каким бы привлекательным ни был мир без null, он представляет большие трудности для многих существующих паттернов и конструкций. Например, рассмотрим следующие конструкции, которые потребовали бы серьезных изменений, если бы null не существовало.

1. Создание массива ссылочных типов ala: new object[42]. В существующем мире CLR массивы будут заполнены null, что недопустимо. Здесь необходимо немного изменить семантику массива
2. Это делает default(T) полезным только тогда, когда T является типом значения. Использование его в ссылочных типах или неограниченных дженериках запрещено.
3. Поля в структуре, которые являются ссылочным типом, должны быть запрещены. Тип значения может быть инициализирован 0 сегодня в среде CLR, которая удобно заполняет поля ссылочных типов с помощью null. Это было бы невозможно в ненулевом мире, поэтому поля, которые являются ссылочными типами в структуре, должны быть запрещены

Ни одна из вышеперечисленных проблем не является неразрешимой, но они действительно приводят к изменениям, которые действительно бросают вызов тому, как разработчики склонны думать о кодировании. Лично мне хотелось бы, чтобы C # и .Net были разработаны с устранением null, но, к сожалению, это не так, и я полагаю, что проблемы, подобные приведенным выше, были немного связаны с этим.

У нас есть Тони Хоар, пионер, работавший над Алголом. благодарить за это. Он скорее сожалеет об этом:

Я называю это своей ошибкой на миллиард долларов. Это было изобретение нулевой ссылки в 1965 году. В то время я проектировал первую всеобъемлющую систему типов для ссылок на объектно-ориентированном языке (АЛГОЛ W). Моя цель состояла в том, чтобы гарантировать, что любое использование ссылок должно быть абсолютно безопасным, с автоматической проверкой компилятором. Но я не мог устоять перед соблазном вставить пустую ссылку просто потому, что это было так легко реализовать. Это привело к бесчисленным ошибкам, уязвимостям и системным сбоям, которые, вероятно, причинили боль и ущерб на миллиард долларов за последние сорок лет.

Думаю, миллиард - это мелочь.

ОБНОВЛЕНИЕ: у C # версии 8 и .NETCore есть достойное решение этой проблемы, проверьте ссылочные типы, не допускающие значения NULL.

Это напоминает мне эпизод из серии «Связи» Джеймса Берка, где монахи переводили арабский язык на латынь и впервые столкнулись с нулевой цифрой. Римская арифметика не имела представления для нуля, но арабская / арамейская арифметика имела. «Почему мы должны писать письмо, чтобы ничего не указывать?» утверждали католические монахи. "Если это ничего, мы не должны ничего писать!"

К счастью для современного общества, они проиграли спор и научились записывать нулевые цифры в математике. ;>

Null просто представляет собой отсутствие объекта. Существуют языки программирования, в которых нет «нуля» как такового, но в большинстве из них все же есть что-то, что отражает отсутствие легитимного объекта. Если вы отбросите «null» и замените его чем-то под названием «EmptyObject» или «NullNode», это все равно null, только с другим именем.

Если вы удалите возможность языка программирования представлять переменную или поле, которое не ссылается на законный объект, то есть вы требуете, чтобы каждая переменная и поле всегда содержали истинный и действительный экземпляр объекта, тогда вы сделаете некоторые очень полезные и эффективные структуры данных неудобные и неэффективные, такие как построение связного списка. Вместо использования нуля для обозначения конца связанного списка программист вынужден изобрести «поддельные» экземпляры объектов, которые будут служить терминалами списков, которые ничего не делают, кроме как указывают «здесь ничего нет».

Здесь мы углубляемся в экзистенциализм, но: если вы можете изобразить присутствие чего-то, то разве нет фундаментальной потребности в том, чтобы иметь возможность представлять и его отсутствие?

Я предполагаю, что они существуют null в .NET, потому что он (C #) последовал за шагом в C ++ / Java (и только начал расширяться в более поздних версиях) и VB / J ++ (который стал VB.NET/J#) уже имел понятие значений "ничего", то есть .NET имеет null из-за того, что было, а не из-за того, что он мог Был.

В некоторых языках нет понятия null - null может быть полностью заменен типом, подобным Maybe - есть Something (объект) или Nothing (но это not null! Невозможно получить "Ничего" из "Может быть!")

В Scala с опцией:

val opt = Some("foo") // or perhaps, None
opt match {
   case Some(x) => x.toString() // x not null here, but only by code-contract, e.g. Some(null) would allow it.
   case _ => "nothing :(" // opt contained "Nothing"
}

Это делается языковым дизайном в Haskell (null невозможно ... вообще!) И поддержкой библиотеки и осторожным использованием, например, в Scala, как показано выше. (Scala поддерживает null - возможно, для взаимодействия Java / C # - но можно писать код Scala без использования этого факта, если только null не разрешено «просачиваться»).

Изменить: см. Scala: Option Pattern. , Scala: Option Cheat Cheet и SO: используйте Maybe Type в Haskell. В большинстве случаев разговор о Maybe в Haskell затрагивает тему монад. Я не буду утверждать, что понимаю их, но вот ссылка вместе с использованием Может быть.

Удачного кодирования.

Хорошо, теперь перейдем к волшебному слову C # -without-null

class View
{
    Model model;        

    public View(Model model)
    {
        Console.WriteLine("my model : {0}, thing : {1}", this.model, this.model.thing);
        this.model = model;
    }
}

Что напечатано на консоли?

• Ничего особенного при доступе к неинициализированному объекту не генерируется: Хорошо, назовите это NullReferenceException и это текущий мир.
• Он не строится, пользователю нужно было указать значение при объявлении модели, см. Последний пункт, поскольку он дает тот же результат.
• Некоторое значение по умолчанию для модели и какое-то значение по умолчанию для вещи: Хорошо, раньше с null у нас, по крайней мере, был способ узнать, был ли экземпляр правильным, теперь компилятор генерирует странные двойники, которые ничего не содержат, но все еще недействительны как модель объекты...
• Что-то, определяемое типом объектов: лучше, поскольку мы могли бы определить конкретное недопустимое состояние для каждого объекта, но теперь каждый объект, который может быть недопустимым, должен независимо реализовать это вместе со способом идентификации этого состояния вызывающей стороной ...

Так что в основном для меня это, похоже, ничего не решает, чтобы удалить нулевое состояние, поскольку возможно недопустимое состояние все равно нужно управлять ...

О, купите путь, какое значение будет по умолчанию для интерфейса? Да, и абстрактный класс, что произойдет, когда метод будет вызван со значением по умолчанию, которое определено в абстрактном классе, но которое вызывает другой абстрактный метод? .... .... Зачем усложнять модель, это снова вопросы множественного наследования!

Одним из решений было бы полностью изменить синтаксис, чтобы перейти на полнофункциональный, где нулевой мир не выходит, только Maybes, когда вы хотите, чтобы они существовали ... Но это не C-подобный язык и многопарадигмальность из .Net будет потеряно.

Чего может не хватать, так это оператора с нулевым распространением, способного возвращать null в model.Thing, когда модель имеет значение NULL, например model.?.Thing

Ну и напоследок ответим на ваш вопрос:

• Текущая библиотека классов развивалась после фиаско Microsoft-Java, и C # был создан как «улучшенная Java», поэтому изменение системы типов для удаления нулевых ссылок было бы большим изменением. Им уже удалось ввести ценностные типы и убрать ручной бокс!
• Как видно из введения типа значения, Microsoft много думает о скорости ... Тот факт, что значение по умолчанию для всех типов соответствует нулевой заливке, действительно важен, например, для быстрой инициализации массива. В противном случае инициализация массивов справочных значений потребовала бы особого внимания.
• Без нулевого взаимодействия с C было бы невозможно, поэтому, по крайней мере, на уровне MSIL и в небезопасном блоке им нужно позволить выжить.
• Microsoft хотела использовать фреймворк для VB6 ++, удалив Nothing, как он называется в VB, радикально изменил бы язык, пользователям уже потребовались годы, чтобы переключиться с VB6 на VB.Net, такое изменение парадигмы могло быть фатальным для языка.

Ну, значения (переменные типа значения) могут быть только null, поскольку типы, допускающие значение NULL, были введены в Fx2.

Но я полагаю, вы имеете в виду:

Почему ссылки могут быть null?

Это часть полезности ссылок. Рассмотрим дерево или LinkedList, они были бы невозможны (не могли бы закончиться) без null.

Вы можете привести еще много примеров, но в основном null существует для моделирования концепции «необязательных» свойств / отношений.

Истерический изюм.

Это пережиток языков C-уровня, где вы живете за счет явных манипуляций с указателями. Современные декларативные языки (Mercury, Haskell, OCaml и др.) Вполне успешно обходятся без нулей. Здесь каждое значение должно быть явно построено. Идея «null» реализуется через типы «option», которые имеют два значения: «no» (соответствует null) и «yes (x)» (соответствует ненулевому значению x). Вы должны распаковать каждое значение параметра, чтобы решить, что делать, следовательно: нет ошибок ссылки на нулевой указатель.

Отсутствие нулей в языке избавляет вас от многих проблем, очень жаль, что идея все еще сохраняется в языках высокого уровня.

Я тоже не знаком с альтернативами, но я не вижу разницы между Object.Empty и null, кроме null, чтобы вы знали, что что-то не так, когда ваш код пытается получить доступ к объекту, тогда как Object.Empty разрешает обработку для Продолжать. Иногда вам нужно одно поведение, а иногда другое. Отличие null от Empty - полезный инструмент для этого.

Для обозначения концепции небытия, поскольку 0 не подходит.

Теперь вы можете присвоить любому типу значения значение Null, определив тип, допускающий значение NULL.

Я думаю, что мы не можем всегда иметь значение для переменной, потому что сначала мы должны установить для нее какое-то значение по умолчанию, и здесь возникает вопрос, почему конкретное значение имеет преимущество перед другими.

Многие люди, вероятно, не могут осмыслить кодирование без нулей, и, если бы в C # не было нулей, я сомневаюсь, что он бы так прижился.

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

Например,

Person? person = SearchForPersonByFirstName("Steve");
if (person.HasValue)
{
    Console.WriteLine("Hi, " + person.Value.FullName);
}

К сожалению, когда вышел C # 1.0, не было концепции Nullable; это было добавлено в C # 2.0. Принуждение ссылок к значениям нарушило бы старые программы.

null - это просто имя значения по умолчанию для ссылочного типа. Если null не было разрешено, то понятие «не имеет значения» не исчезло бы, вы бы просто представили его по-другому. Помимо специального имени, это значение по умолчанию также имеет особую семантику в случае неправильного использования - т.е. если вы относитесь к нему как к значению, а на самом деле его нет.

Если бы не было null:

1. Вам нужно будет определить контрольные значения по умолчанию для ваших типов, которые будут использоваться, когда «нет значения». В качестве тривиального примера рассмотрим последний узел прямого односвязного списка.
2. Вам нужно будет определить семантику для операций, выполняемых со всеми этими контрольными значениями.
3. Среда выполнения будет иметь дополнительные накладные расходы на обработку контрольных значений. В современных виртуальных машинах, таких как те, которые используются .NET и Java, нет накладных расходов на проверку нуля перед вызовом большинства функций и разыменованием, потому что ЦП предоставляет специальные способы обработки этого случая, а ЦП оптимизирован для случаев, когда ссылки не равны нулю (например, предсказание ветвления).

В итоге:

• Название изменится, а концепция - нет.
• Бремя определения и передачи значения и семантики по умолчанию для случаев, когда у вас нет значения, возлагается на разработчиков и документацию для разработчиков.
• Выполнение кода на современных виртуальных машинах столкнется с раздуванием кода и существенным снижением производительности для многих алгоритмов.

Проблемы с null, описанные Тони Хоаром, обычно связаны с тем, что до появления современных виртуальных машин в системах времени выполнения не было почти такой чистой обработки неправильно используемых значений null, как сегодня. Неправильное использование указателей / ссылок остается проблемой, но отследить проблему при работе с .NET или Java, как правило, намного проще, чем раньше, например С.