OberonCore

Какая-то странная логика - ну и что с того?
Если отсутствие (и способ установления связи) - не артефакт, а элемент модели, внешней по отношению к собственно написанию кода, и код был написан плохо (плохо структурировался, раз что-то забыли...), то причём тут NIL-то? Это как ребёнок, ушибившийся об угол табуретки, начинает её бить за то, что она плохая...

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

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

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

Конкретно на такую постановку отвечаю: ничем не противоестественна. Про грабли я рассказал применительно к вашему же вопросу про "существо проблемы с nil" (то самое существо, с которым в ФП несколько лучше).

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

Не, извините. Не надо опять все сваливать на правильное проектирование. Правильное проектирование - это очень хорошо. И правильное тестирование - это тоже очень хорошо. Речь не идет даже о выборе какого-то компромисса: "нулевые ссылки позволяют лучше проектировать" или "нулевые сылки позволяют лучше тестировать" (в отличие, например, от случая динамическая типизация vs статическая типизация). Нулевые ссылки создают проблемы сами по себе, независимо от.

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

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

Воистину! Вон, и Ариан-5 упал от той же фразы (скорость ракеты никогда не будет выше вот этого-то).

А ещё мне нравится фраза: "ну и что что конструкция/модуль/класc/etc позволяет ей неправильно воспользоваться, мы то ведь не будем её так (неправильно) использовать!"

(чаще всего слышал при обсуждении архитектуры где было широкое использование void* , например в списках, в параметрах функций и проч. Ну и что, что сведения о типе теряются? Мы ведь не будем приводить к типу отличному от того что туда положим! Зато универсально!).

Я же сказал: "для модели, для которой отсутствие связи не артефакт - все хорошо". Проблемы начинаются с моделями, в которых отсутствие связи - артефакт. Вот, например, возьмем мою любимую базу данных и форму, которая из этой БД что-то отображает. В такой модели отсутствие связи с БД (нулевая ссылка) - артефакт. Ну нечего показывать этой форме без БД. Даже если вы захотите корректно обрабатывать ситуацию, когда с БД случилось что-то страшное, вы не будете это делать в форме (надеюсь такое проектное решение не вызывает вопросов?) Так зачем мне в форме иметь возможность получить нулевую ссылку на БД? Чтобы упасть с ASSERT'ом/NIL dereference/AV?

Согласен. Но при чём тут NIL-ы сами по себе

Ну, можно попытаться обязать программиста всегда направлять ссылку на что-нибудь. Тогда вместо NIL будут подставлять заглушки, но в некоторых ситуациях понуждение устанавливать связь сразу может дисциплинировать. Как это оформить синтаксически в классическом ЯП без загромождения - трудно представить, ещё труднее сделать... В однородном языке типа Smalltalk можно представить себе, что при создании объекта все его поля-ссылки указывают на некие "пустышки". Т.е. тот же NIL, но он готов обработать (проигнорировать) любое сообщение. Что это даст - тоже непонятно.

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

Дебри, дебри. Для борьбы с весьма редкой и не опасной ситуацией (она ведь локальна, не ведёт к разрушению, вылавливается вашими любимыми модульными тестами на раз, вместе с опечатками...).

При том, что нет NIL'ов - нет проблем



Да, но согласитесь, что подстановка заглушки - более осмысленное действие, чем просто NIL Более явное, как минимум.



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



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



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

Чё-т я не пойму, в чём конкретно проблема? NIL, в данном случае входит в пространство состояний вашего случая? Это - чётко обозначенное и осмысленное "значение"? С "навешанными" на него смыслами и реакциями элементов модели? Так в чём - таки вопрос и - "опасность" от такого NIL-а?

Тут скорее речь должна не о конкретном значении указателя "NIL" идти, а о значении "вне диапазона"...
В Си о таком даже смысла нет рассуждать. Практически во всем современных языках. Кроме тех, что обладают дескрипторной моделью представления объектов (да ещё и имеют поддержку от аппаратуры)... Но Эльбрус и Интел 432 приказали долго жить, а что-то приемлемого на горизонте не видать...
Меньшее зло - иметь такую поддержку со стороны системы времени исполнения... Но там начинаются огромные накладные расходы. Они меньше в языках без указателей и а ля Обероны, но тут уже возникает субъективный фактор...

Замкнутый круг!

На каждой итерации которого Vlad сходится со мной, или Geneipro - с Ильёй...

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

А я, тем временем, ужасаюсь архитектурами Линуха и BSD и офигеваю от правильности эпиграфа (про дятла...) к первой главе Буча...

Ох...



Ну давайте новыми словами. NIL - не входит в пространство состояний. И я не хочу его видеть в рамках моей модели. Мало того, я не хочу, чтобы кто-то другой "случайно" передал NIL на вход моей модели (и моя модель упала). Что тут непонятного?



Ох куда вас понесло... Да, мир несовершенен Но я же не прошу многого, я не прошу никакой аппаратной поддержки, я всего лишь прошу убрать (а не добавить) NIL. Отрезать ненужное - это как раз в духе оберонов



В том-то и дело, убирание NIL не требует никаких расходов. Всего лишь ломание искусственно созданных стереотипов

Собственно, вместо состояния NIL ("ни на что не указывает") состояние "ещё неинициализировано", ведущее к ошибке при попытке использования - я правильно понял, Вы это предлагаете? (я про это и говорил выше).

Нет. Я предлагаю вообще избавиться от "ошибки при попытке использования". Нет состояния "ещё неинициализировано" для ссылки. Ссылка всегда инициализирована. Это контролирует компилятор (и реализовать это совсем не сложно).
Естественно, что для поддержки случая, когда "связь может быть не установлена" потребуется еще одна сущность. Но это будет не ссылка. Это будет что-то, что может быть приведено к ссылке только явно (как приведение типа).

Да уж, действительно - ОХ!

Vlad! Да Вы УЖЕ говорите о NIL, как о полноправном участнике Вашей модели! Вы уже его в свою модель ввели! Самим своим описанием своего же "нежелания видеть" и "получать о кого-нибудь"!
Ну хорошо, а опишите мне тогда состояние "не имеет значения", "не инициализирован", "не определён"? ВВодить "доп поля" у "объектов ссылок"? Заключать соглашение о том, что в каждом типе будет своё "типизированное ПУСТО"?
Ну да, ну да... "Бытие - это то, что есть, а небытие - это то, чего нет... Но того, чего нет, - быть не может. Следовательно, небытия нет..."

Ох! Если бы говоря "я не хочу яблок" я бы получал от кого-нибудь яблоки, то с пропитанием было бы проще



Это была шутка. Да, действительно, наряду с убиранием NIL'а потребуется сущность для описания состояния "связь еще не установлена".



Ну это самое очевидное. Почему нет? Тем более, что прецеденты даже в мэйнстриме есть.

Ух! Речь то, не о том, что на Ваше требование Вам именно это и давали, а о том, что Вам-таки НИЧЕГО не дадут. И это "ничего", вы должны как-то зафиксировать и отразить (кроме урчания в желудке, ессно)...
Но ведь мы рассуждаем о ссылках, а не о скалярных типах! У нас уже есть такое "значение" с таким смыслом - NIL!
ЗАЧЕМ ПЛОДИТЬ СУЩНОСТИ?
Они и правилам наследования и присвоения будут соответствовать?
Ото самое, чего НЕТ?

Я и предлагаю зафиксировать - отменить нулевые ссылки.



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



Вот в обероне есть понятие типа, а есть понятие массива. У вас не возникало желания наследовать массив? С признаком "возможной неинициализированности" все тоже самое. Это ортогональная к типам сущность.

Реальный, осмысленный вариант - именно изменение семантики NIL, имхо.
А остальное - какая-то утопия по вытеснению неизвестно чего неизвестно куда. С моей удивлённой точки зрения.

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