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

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

Смотрите:

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

для обсуждения API хранения ключевых значений

Ответ 1

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

Ответ 2

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

То, о чем вы говорите, это тип суммы (проверьте "Типы и языки программирования" ).

То есть тип, который имеет n + 1 жителей. То есть тип, чьи элементы:

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

ИЛИ

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

Это легко описывается как тип алгебраических данных, например. в Haskell

data Maybe a = Just a | Nothing

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

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

Ответ 3

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

Ответ 4

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

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

Ответ 5

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