Какова цель null?

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

Есть ли у вас какие-либо мысли, особенно за или против null? Вы когда-нибудь создавали функциональные возможности, которые требовали нулевого?

Ответ 1

Null: ошибка в миллиард долларов. Тони Хоар:

Я называю это своей ошибкой в ​​миллиард долларов. Это было изобретение нулевого в 1965 году. В то время я был проектирование первого комплексного типа система для ссылок в объекте ориентированный язык (ALGOL W). Моя цель заключается в обеспечении того, чтобы все виды использования ссылки должны быть абсолютно безопасными, с автоматической проверкой компилятором. Но я не мог сопротивляться соблазн положить в нуль ссылку, просто потому, что это было так легко реализуется. Это привело к бесчисленные ошибки, уязвимости, и системные сбои, которые вероятно, вызвало миллиард долларов боль и повреждение в последние сорок лет года. В последние годы ряд программные анализаторы, такие как PREfix и PREfast в Microsoft были использованы для проверить ссылки и дать предупреждения, если существует риск, что они могут быть не нулевыми.Более свежие языки программирования, такие как SpeС# представили объявления для ненулевые ссылки. Это решение, которое я отклонил в 1965 году.

Ответ 2

null - это дозорное значение, которое не является целым числом, а не строкой, а не булевым - не что-то действительно, кроме того, что нужно удерживать и быть значением "не существует". Не рассматривайте его как ожидаемое значение 0 или пустую строку или пустой список. Это все допустимые значения и могут быть гениально достоверными значениями во многих случаях - идея null вместо этого означает, что там нет никакой ценности.

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

Ответ 3

О нет, я чувствую, что из меня вышла основная философия...

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

В языках программирования я думаю, что очень полезно понимать ссылки на объекты, которые не относятся ни к чему в памяти. Google о теории множеств, и вы увидите сходство между формальными символическими системами (обозначение), которые используют теоретики, и символы, которые мы используем на многих компьютерных языках.

С уважением, Сэм

Ответ 4

Какой нуль для вас спросите?

Ну,

Ничего.

Ответ 5

Я обычно думаю о "null" в аспекте C/С++ "адрес памяти 0". Это не строго необходимо, но если бы этого не было, тогда люди просто использовали бы что-то другое (если myNumber == -1, или если myString == "").

Все, что я знаю, я не могу придумать того дня, когда я провел кодирование, что я не набрал слово "null", поэтому я думаю, что это делает его очень важным.

В мире .NET MS недавно добавила типы с нулевым значением для int, long и т.д., которые никогда не использовались для NULL, поэтому я думаю, они думают, что это тоже очень важно.

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

Ответ 6

понятие null не является строго необходимым в том же смысле, что понятие нуля не является строго необходимым.

Ответ 7

Я не думаю, что полезно говорить об отсутствии вне контекста всего дизайна языка. Первая точка путаницы: пустой пуст, или он включает в себя одно выделенное значение (часто называемое "nil" )? Полностью пустой тип не очень полезен --- хотя C использует пустой тип возвращаемого значения void для обозначения процедуры, которая выполняется только для побочного эффекта, для многих других языков используется один тип (обычно пустой кортеж).

Я нахожу, что значение nil наиболее эффективно используется в динамически типизированных языках. В Smalltalk это значение используется, когда вам нужно значение, но у вас нет никакой информации. В Lua он используется еще эффективнее: значение nil является единственным значением, которое не может быть ключом или значением в таблице Lua. В Lua значение nil также используется как значение отсутствующих параметров или результатов.

В целом я бы сказал, что значение nil может быть полезно в динамически типизированном параметре, но в статически типизированном параметре нулевой тип полезен только для обсуждения функций (или процедур или методов), которые выполняются для побочного эффекта.

Во что бы то ни стало, избегайте указателя NULL, используемого в C и Java. Это артефакты, присущие реализациям указателей и объектов, и в хорошо продуманном lanugage они не должны допускаться. Во что бы то ни стало дайте своим пользователям возможность расширить существующий тип с нулевым значением, но заставляйте их делать это явно, специально - не заставляйте каждый тип иметь один случайно. (В качестве примера явного использования я недавно применил тройные деревья поиска Bentley и Sedgewick в Haskell, и мне нужно было расширить тип символа одним дополнительным значением, означающим "не символ". Для этого Haskell предоставляет тип Maybe. )

Наконец, если вы пишете компилятор, хорошо помнить, что самые простые части языка для компиляции и части, которые вызывают наименьшие ошибки, являются частями, которых там нет: -)

Ответ 8

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

Ответ 9

В C NULL было (void * (0)), поэтому это был тип со значением (?). Но это не сработало с С++-шаблонами, поэтому С++ сделал NULL 0, он сбросил тип и стал чистым значением.

Однако было обнаружено, что наличие определенного типа NULL будет лучше, поэтому они (комитет С++) решили, что NULL снова станет типом (в С++ 0x).

Также почти каждый язык, кроме С++, имеет NULL как тип или эквивалентное уникальное значение, не то же самое, что и 0 (он может быть равен ему или нет, но его не то же значение).

Итак, теперь даже С++ будет использовать NULL как тип, в основном закрывая обсуждения по этому вопросу, так как теперь все (почти) будут иметь тип NULL

Изменить: Размышление об этом. Haskell, возможно, другое решение для типов NULL, но его не так легко понять или реализовать.

Ответ 10

Вы можете представить любой тип в виде набора вместе с набором операций. Есть много случаев, когда удобно иметь значение с не является "нормальным" значением; например, рассмотреть значение "EOF". для C getline(). Вы можете обработать это одним из нескольких способов: у вас может быть значение NULL вне набора, вы можете отличить конкретное значение как null (в C, ((void *)0) может служить этой цели), или вы можете создать способ создания нового type, так что для типа T вы создаете тип T '= def {T & cup; NULL}, что делает Haskell (тип "Maybe" ).

Какой из них лучше подходит для многих приятных аргументов.

Ответ 11

Рассмотрим примеры C и Java, например. В C соглашение состоит в том, что нулевой указатель представляет собой числовое значение ноль. Конечно, это действительно просто конвенция: ничто о языке не относится к этой ценности как к чему-то особенному. В Java, однако, null - это отличная концепция, которую вы можете обнаружить и знать, что да, это на самом деле плохая рекомендация, и я не должен пытаться открыть эту дверь, чтобы увидеть, что с другой стороны.

Тем не менее, я ненавижу нули почти хуже всего.

CLARIFICATION на основе комментариев: Я ненавижу значение defacto null указателя нуля хуже, чем я ненавижу null.

В любой момент, когда я вижу присвоение null, я думаю: "О, хорошо, кто-то просто поместил мишень в код. Когда-нибудь мы пройдем по соответствующему пути выполнения и BOOM! NullPointerException!"

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

Тем не менее, он все же лучше, чем сырой нуль, блуждающий вокруг.

Ответ 12

Нуль - не ошибка. Null означает "Я еще не знаю"

Для примитивов вам действительно не нужен нуль (я должен сказать, что строки (в .NET) не должны получать IMHO)

Но для составных объектов это определенно служит цели.

Ответ 13

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

Ответ 14

Null - это контрольное значение. Это значение, которое не может быть реальными данными и вместо этого предоставляет метаданные о используемой переменной.

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

Кроме того, нулевой символ в строке переменной длины C-стиля используется для обозначения конца строки.

Использование null этими способами, особенно для значений указателей, стало настолько популярным, что метафора была импортирована в другие системы, даже если значение "нулевой" дозорное реализовано совершенно по-другому и не имеет никакого отношения к числу 0.

Ответ 15

Нуль - это не проблема - все, кто обрабатывает и интерпретирует null по-разному, является проблемой.

Мне нравится null. Если бы не было нулевого значения, null был бы заменен другим способом для кода: "У меня нет подсказки, чувак!". (которые некоторые напишут "У меня нет подсказки, человек!", или "У меня нет подсказки, старый bean!" и т.д., и поэтому у нас бы были проблемы с теми же проблемами).

Я обобщаю, я знаю.

Ответ 16

Практический пример null - это когда вы задаете вопрос "да/нет" и не получаете ответа. Вы не хотите, чтобы по умолчанию не было, потому что может быть важно знать, что на вопрос не был дан ответ в ситуациях, когда ответ очень важен.

Ответ 17

Это решение зависит от цели языка программирования.

Для кого вы разрабатываете язык программирования? Вы разрабатываете его для людей, знакомых с c-производными языками? Если это так, то вам, вероятно, следует добавить поддержку null.

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

В качестве примера возьмите блоки-переключатели на С#. Все метки меток на С# должны иметь явное выражение потока управления в каждой ветки. То есть все они должны заканчиваться либо выражением "break", либо явным goto. Это означает, что, хотя этот код является законным:

switch(x)
{
    case 1:
    case 2:
        foo;
        break;
}

Что этот код не будет законным:

switch (x)
{
    case 1:
        foo();
    case 2:
        bar();
        break;
}

Чтобы создать "провал" от случая 1 к случаю 2, необходимо вставить goto, например:

switch (x)
{
    case 1:
        foo();
        goto case 2;
    case 2:
        bar();
        break;
}

Это, возможно, что-то, что нарушит ожидания программистов на C++, склоняющихся к С#. Однако добавление этого ограничения служит целям. Это исключает возможность использования всего класса общих ошибок С++. Это немного добавляет к кривой обучения язык, но результат является чистой выгодой для программиста.

Если ваша цель - создать язык, ориентированный на программистов на С++, то удаление null, вероятно, нарушит их ожидания. Это вызовет путаницу и затруднит изучение вашего языка. Ключевой вопрос заключается в том, "какую пользу они получают"? Или, альтернативно, "какой ущерб причиняет это".

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

Итак, чтобы повторить, я бы сказал, что вам нужно:

  • Определите свои цели при создании языка. Для кого предназначен язык и каковы его потребности.
  • Примите решение на основе того, что помогает целевым пользователям наилучшим образом выполнить свои задачи.

Обычно это делает желаемый результат довольно ясным.

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

Ответ 18

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

Это только одна перспектива, о которой я не вижу раньше.

Ответ 19

Какую цель дает null?

Я считаю, что здесь есть два понятия null.

Первый (нулевой логический индикатор) является традиционным механизмом языка программы, который обеспечивает отображение времени выполнения неинициализированной памяти в логике программы.

Второй (значение null) - это базовое значение данных, которое может использоваться в логических выражениях для обнаружения логического нулевого индикатора (предыдущее определение) и принятия логических решений в программном коде.

Есть ли у вас какие-либо мысли, особенно для или против null?

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

Итог, все зависит от целей вашего языка:

  • целевая аудитория программы
  • робастности
  • производительности
  • и т.д...

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

ВВ

Ответ 20

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

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

Ответ 21

Null - это заполнитель, который означает, что никакая ценность (добавление "правильного типа" для статического типизированного языка) может быть назначена этой переменной.

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

Ответ 22

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

Ответ 23

Используйте шаблон нулевого объекта!

Если язык ориентирован на объекты, пусть он имеет класс UndefinedValue, из которого только один экземпляр singleton существует. Затем используйте этот экземпляр, где используется null. Это имеет то преимущество, что ваш null будет отвечать на сообщения, такие как #toString и #equals. Вы никогда не столкнетесь с исключением с нулевым указателем, как в Java. (Конечно, для этого требуется, чтобы ваш язык был динамически напечатан).

Ответ 24

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

Вначале может показаться очевидным, что это должно означать "нет значения", но то, что НАСТОЯТЕЛЬНО означает, зависит от контекста. Если, например, LastName === null, означает ли это, что у человека нет фамилии или что мы не знаем, что такое их фамилия, или что он еще не введен в систему? Нулевое значение равно или не так ли? В SQL это не так. На многих языках это происходит. Но если мы не знаем значения personA.lastName или personB.lastName, как мы можем узнать, что personA.lastName === personB.lastName, а? Если результат будет ложным или.... ноль?

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

Вам намного лучше определить DOMAIN возможных значений lastName и точно, что на самом деле означает любое возможное значение, а не зависящее от некоторого неопределенного общенационального понятия null, которое может иметь или не иметь никакого отношения к тому, что вы "в зависимости от того, какой язык вы используете, и что вы пытаетесь сделать. Значение, которое на самом деле может вести себя точно так же, когда вы начнете работать с вашими данными.

Ответ 25

Null - это объекты, для которых 0 - числа.