| x =/= y |
Таблица 8.3.Нотация в стиле Simula для операций со ссылками и значениями развернутых типов
Соглашения Simula лишены неоднозначности. Почему бы их не сохранить? К сожалению, эти соглашения могут служить примером благих намерений, приносящих скорее вред, нежели пользу. Проблемы начинаются в прозаической области поиска ошибок. Два набора символов похожи, - это провоцирует синтаксические ошибки, подобные использованию
Такие ошибки будут обнаружены компилятором. Но хотя ограничения, проверяемые компилятором, предназначены помочь программисту, - здесь это может не сработать. Либо вы знаете разницу между семантикой ссылок и значений, и тогда подсказки компилятора о необходимости проверки, каждый раз, когда вы написали присваивание или равенство, могут показаться раздражающими. Либо вы не понимаете этой разницы, тогда его подсказки немногим могут помочь.
Но самый важный аспект соглашений Simula в том, что он не оставляет выбора: для ссылок нет доступной конструкции, дающей семантику значений. Представляется разумным для сущностей
[x].
[x].
Но за одним исключением, Simula поддерживает только первое множество операций. Если необходимы операции второго множества (
Кстати, при дальнейшем анализе идея предоставления двух множеств операций для всех ссылочных типов не кажется уже столь разумной. Это бы означало, что тривиальная описка - использование
Как результат этого анализа, нотация этой книги использует соглашения, отличные от тех, что используются в Simula: одни и те же символы применимы для развернутых и ссылочных типов с различной семантикой. Эффекта семантики значений можно достигнуть для объектов ссылочного типа при использовании предопределенных подпрограмм, применимых для всех типов:
[x].
[x].
Эта нотация существенно отличается от нотации, применяемой для их ссылочных двойников, (
Помимо чисто синтаксических аспектов, эта проблема интересна и тем, что она представляет типичный образец компромиссов, возникающих при проектировании языка, когда требуется найти баланс между конфликтующими критериями. Один из критериев, победивших в Simula, - может быть сформулирован следующим образом:
[x]. 'Выражайте различные концепции с помощью различных символов'.
Но другие силы, доминирующие в нашей нотации, требуют:
[x]. 'Не создавайте разработчику лишних проблем'.
[x]. 'Тщательно взвешивайте все 'за и против' любой новинки, обращая особое внимание на безопасность и качество'.
[x]. 'Убедитесь, что общие операции могут быть выражены в простой и ясной форме'. Применение этого принципа требует особой тщательности, поскольку проектировщик языка может ошибаться в своих оценках того, что же является наиболее общим случаем. Но в данной ситуации все кажется проще. Для сущностей развернутого типа (таких как
[x]. 'Для сохранения компактности и простоты языка вводите новые обозначения, только если это абсолютно необходимо'. Это справедливо в частности для приведенного примера - существующая нотация работает и не существует опасности путаницы.
[x]. 'Если вы знаете, что существует риск возникновения недоразумений между двумя возможностями, то соответствующие нотации должны различаться очевидным образом'. Так что необходимо избегать использования символов, близких по написанию (
Еще одна причина играет роль в данном случае, хотя она включает механизм, пока еще не изученный. В последующих лекциях мы познакомимся с родовыми или универсальными классами, такими как
| Примером подпрограммы, нуждающейся в таком дуальном поведении, является процедура вставки элемента |
В таких случаях, правила, определенные выше, гарантируют желаемое дуальное поведение, что было бы недостижимо, если бы требовался различный синтаксис для двух видов семантики. С другой стороны, если во всех случаях требуется единая семантика, то и это достижимо: такое поведение может быть только семантикой значений (так как семантика ссылок не имеет смысла для развернутых типов);
