Комментарии 13
Новое поветрие - давайте будем бороться с null, а то есть ещё undef...
А в чем вообще эта проблема с NULL? Ну примите за NULL числовое значение, которое указывает на какую-нибудь ненужную или несуществующую область памяти. И пусть переменная ссылается туда сколько ей угодно.
Это ровно та имплементация, которая проблемна. И не столько с точки зрения наличия NULL как такового, но смешивания ссылочного типа с числовым типом. Так это сделано, например, в C и это (по моим оценкам) самый частый источник ошибок вида SEGFAULT, когда происходит доступ к недоступной области памяти.
Я дико извиняюсь, если оскорблю кого-нибудь своей невежественностью, но как еще, кроме NULL, удобно обозначать в предметной области контролируемое частичное отсутствие данных?
То есть, это не когда данных совсем нет, а, например, нет с одного датчика. С десяти датчиков есть, а с одного нет...
Абстракция NULL, как по мне, так вполне себе удобный инструмент. И, если кто-то выхватил null reference крэш, то, как мне кажется, где-то пропущен edge кейс, и это повод улучшить контроль потока данных.
Просто программисты, похоже, тупеют, им надо специально указывать что не надо через NULL в память лезть, не надо ложку в глаз совать, не надо сушить голову в микроволновке...
Ваш случай отлично ложится в контейнеры. Можно использовать условный list или map, в котором просто не будет отсутствующих ключей. В этом и смысл: не описывать то, чего не существует.
Мой случай уже лежит в контейнерах ;-)
Я Вас понимаю, но не совсем согласен. На мой взгляд, отсутствие ключа в схеме данных породит неоднозначность трактовки: то ли данные не пришли, то ли что-то скривилось и мы источник не обработали..
Да, с точки зрения утилизации памяти, СХД это, наверное, не плохая идея - хранение нуллов так себе затея. Так ведь мы данные храним не просто так, а с целью их последующего использования, и вот в этот момент хотелось бы иметь больше однозначности в том, как интерпретировать отсутствие данных.
определённо ясно, что NULL — исключительно техническая необходимость. А в моделировании предметной области использовать NULL просто не получится.
Заодно предлагаю отказаться от концепции нуля и отрицательных чисел.
Уже давно все есть в современных языках. Например тип NonZero в Rust. https://doc.rust-lang.org/core/num/struct.NonZero.html
Ещё из SQL надо выпиливать NULL по хорошему. Он просто ломает реляционную логику. Даже сам автор признавался, что это был костыль...
Зерно здравого смысла, конечно, в его докладе есть. Просто чем клеймить NULL надо признать, что как раз таки NULL это то что мы видим в реальном мире: отсутствие чего-то (не всегда равно нулю) или отсутствие информации о чём-либо это и есть NULL. Просто при проектировании языков (особенно не для ФП) мало заморачивались со строгими системами типов, не додумались до Optional<> сразу, что бы запретить программисту не обрабатывать все ситуации. Но ничего, тот же Kotlin живет с этим. И код читаемый и надежный (если через рефлексию не быть ССЗБ).
Так что кажется проблема не в NULL, а в том что не научились с ним жить и не стрелять себе в ногу. Явление открыли, а мат аппарат не проработали и/или не подтянули. Бывает. Комплексной/мнимой единицы i вообще на первый взгляд в природе не существует, ну так и что же, запретить ее?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Про Null References. Популярные современные ЯП позволяют переменным-ссылкам иметь значение NULL. И это уже привело к...