Все ли языки программирования имеют четкую концепцию NIL, null или undefined?

Question

Я пишу API хранилища значений ключей (например, ODBC, только интерфейс, а не базовое хранилище) на многих разных языках, и хотя я не хочу транслитерировать API между языками, я не хочу, например, хранить значение из Java как «ноль», а затем прочитать его на другом языке, который не поддерживает концепцию ноль. Я не уверен, объясняю ли я это так хорошо, но это моя первая попытка:)

См .:

Является ли этот API слишком простым?

за обсуждение API хранилища ключей-значений

Answer 1

Это системный вопрос типа, поэтому любой, кто отвечает на «0», упускает суть.

Вы говорите о типе суммы (отметьте «Типы и языки программирования»).

То есть тип, имеющий n + 1 жителей. То есть тип, чьи элементы являются:

• все значения типа, который вам небезразличен

OR

• дополнительное значение, ничего.

Это легко описать как алгебраический тип данных, например, в Хаскеле

data Maybe a = Just a | Nothing

Как ни странно, относительно немногие языки поддерживают типы сумм, поэтому они кодируют их как продукты (пара тегов Just или Nothing и само значение) или перегружая одного из жителей типа (например, -1 или 0 становится Ничего).

Этот тип обычно известен как Возможно или Необязательно.

Answer 2

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

Answer 3

Если нет, язык должен предоставить альтернативное соглашение, такое как функция isAgeNull.Это не должно вас волновать.
Все основные базы данных имеют значения NULL (и даже типы NULL), и они хорошо работают на разных языках.
Также следует помнить, что существует разница между нулевым указателем объекта . и база данных нулевое значение .

Answer 4

Нет, не все языки поддерживают концепцию "null / nil / Nothing"; также в некоторых случаях такая поддержка ограничивается простым соглашением, согласно которому неизвестное / неопределенное значение представляется конкретным значением.

Я предлагаю вам просто обработать «NULL / Nothing / nil», как если бы это был просто определенный «тип».
Другими словами, точно так же, как вам может быть удобно предоставлять поддержку, скажем, арифметических значений с плавающей запятой (даже если не все языки поддерживают их), если вы находите NULL полезным, вы можете включить его в свою модель данных / API и просто поместить ответственность за конкретные реализации API за преобразование NULL в любое подходящее значение (скажем, ноль или пустую строку или что-то еще) будет лежать в основе языка, не поддерживающего концепцию NULL (или, альтернативно, выдавать исключение, если нежелательно иметь дело с нулем). значения на определенном языке).

Answer 5

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