Должны Ссылки на Языках Объектно-ориентированного программирования быть Не допускающими NULL-значения по умолчанию? [закрытый]

Мне нравится, как Ocaml решает проблему "возможно, ноль". Каждый раз, когда значение типа 'a может быть неизвестным / неопределенным / унифицированным, оно оборачивается в тип ' a Option , который может иметь значение None или Некоторые x , где x - фактическое значение, не допускающее обнуления. При доступе к x вам необходимо использовать механизм сопоставления для разворачивания. Вот функция, которая увеличивает целое число, допускающее значение NULL, и возвращает 0 на None

>>> let f = function  Some x -> x+1 | None->0 ;;
val f : int option -> int = <fun>

Как это работает:

>>> f Some 5 ;;
- : int = 6
>>> f None ;;
- : int = 0

Механизм сопоставления заставляет вас рассматривать случай None . Вот что происходит, если вы его забудете:

 >>> let f = function  Some x -> x+1 ;;
 Characters 8-31:
 let f = function  Some x -> x+1 ;;
         ^^^^^^^^^^^^^^^^^^^^^^^
 Warning P: this pattern-matching is not exhaustive.
 Here is an example of a value that is not matched:
 None
 val f : int option -> int = <fun>

(Это просто предупреждение, а не ошибка. Теперь, если вы передадите None функции, вы получите соответствующее исключение.

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

Нет.

Состояние неинициализировано некоторым образом будет существовать из-за логической необходимости; в настоящее время обозначение отсутствует.

Возможно, можно разработать «действительную, но неинициализированную» концепцию объекта, но чем это существенно отличается? Семантика «доступа к неинициализированному объекту» по-прежнему будет существовать.

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

Насколько я понимаю, обоснование Мартина Одерски для включения null в Scala состоит в том, чтобы легко использовать библиотеки Java (т. Е. Чтобы все ваши api не имели, например, "Object?" place):

http://www.artima.com/scalazine/articles/goals_of_scala.html

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

Если вы объявляете свой столбец с типом метки времени, вы в клевере:

>>> db = sqlite3.connect(':memory:', detect_types=sqlite3.PARSE_DECLTYPES)
>>> c = db.cursor()
>>> c.execute('create table foo (bar integer, baz timestamp)')
<sqlite3.Cursor object at 0x40fc50>
>>> c.execute('insert into foo values(?, ?)', (23, datetime.datetime.now()))
<sqlite3.Cursor object at 0x40fc50>
>>> c.execute('select * from foo')
<sqlite3.Cursor object at 0x40fc50>
>>> c.fetchall()
[(23, datetime.datetime(2009, 12, 1, 19, 31, 1, 40113))]

Видите? как int (для столбца, объявленного как целое число), так и datetime (для столбца, объявленного меткой времени) выдерживают цикл приема-передачи с неизмененным типом.

Думаю, мне следовало быть более явным в моем первоначальном ответе:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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