Чтение онлайн

[x]. "Выражайте различные концепции с помощью различных символов".

Но другие силы, доминирующие в нашей нотации, требуют:

[x]. "Не создавайте разработчику лишних проблем".

[x]. "Тщательно взвешивайте все "за и против" любой новинки, обращая особое внимание на безопасность и качество".

[x]. "Убедитесь, что общие операции могут быть выражены в простой и ясной форме". Применение этого принципа требует особой тщательности, поскольку проектировщик языка может ошибаться в своих оценках того, что же является наиболее общим случаем. Но в данной ситуации все кажется проще. Для сущностей развернутого типа (таких как INTEGER) присваивание и сравнение значений представляются наиболее употребительными операциями. Для ссылок, в то же время, ссылочное сравнение и присваивание используется чаще, чем клонирование, копирование и сравнение объектов. Поэтому в обоих случаях предпочтительнее использовать := и = для фундаментальных операций.

[x]. "Для сохранения компактности и простоты языка вводите новые обозначения, только если это абсолютно необходимо". Это справедливо в частности для приведенного примера - существующая нотация работает и не существует опасности путаницы.

[x]. "Если вы знаете, что существует риск возникновения недоразумений между двумя возможностями, то соответствующие нотации должны различаться очевидным образом". Так что необходимо избегать использования символов, близких по написанию (:- и :=), но с различной семантикой.

Еще одна причина играет роль в данном случае, хотя она включает механизм, пока еще не изученный. В последующих лекциях мы познакомимся с родовыми или универсальными классами, такими как LIST [G], где G, известно как формальный родовой параметр, представляющий произвольный тип. Такой класс может манипулировать сущностями типа G и использовать их в присваиваниях и проверках на равенство. Клиенты, нуждающиеся в использовании такого класса, должны позаботиться о создании типа, служащего в качестве фактического родового параметра. Например, они могут использовать LIST [INTEGER] или LIST [POINT]. Как показывают эти примеры, фактический родовой параметр может быть развернутого типа, как в первом случае, так и ссылочного типа - во втором случае. В подпрограммах такого родового класса, если a и b имеют тип G, то часто полезно использовать присваивания в форме a := b или тесты в форме a = b с намерением получить семантику значений, когда фактический параметр принадлежит развернутому типу, такому как INTEGER, и ссылочную семантику - для ссылочного типа, такого как POINT.

В таких случаях, правила, определенные выше, гарантируют желаемое дуальное поведение, что было бы недостижимо, если бы требовался различный синтаксис для двух видов семантики. С другой стороны, если во всех случаях требуется единая семантика, то и это достижимо: такое поведение может быть только семантикой значений (так как семантика ссылок не имеет смысла для развернутых типов); поэтому в соответствующих подпрограммах следует использовать clone (или copy) и equal, а не (:= и =).

Форма вызова подпрограмм clone и equal является стилевой особенностью, которая может вызвать удивление. На первый взгляд нотация:

выглядит не слишком объектно-ориентированной. Догматичное следование принципу "ОО-стиля вычислений" из предыдущей лекции предполагает другую форму (См. "Объектно-ориентированный стиль вычислений", лекция 7):

В первой версии нотации так и делалось, однако возникла проблема пустых ссылок. Вызов компонента вида x.f (...) не может быть корректно выполнен в случае пустого x во время выполнения. В этом случае вызов инициирует исключение, которое повлечет аварийное завершение всей системы, если в соответствующем классе не предусмотрена обработка исключений. Поскольку во многих случаях x может быть действительно пустой ссылкой, то это означало бы, что каждый вызов twin должен предусматривать охрану и выглядеть так:

Соответственно, реализация вызова is_equal должна выглядеть (and then является вариантом and. См. "Нестрогие булевы операции", лекция 13):

Излишне говорить, что не следует придерживаться этих соглашений. Нам быстро надоест писать подобные витиеватые фрагменты, а когда мы забудем это сделать, то результатом будет ошибка времени выполнения. Окончательный вариант соглашений, сформулированный в данной лекции, замечателен еще и тем, что дает ожидаемые результаты для x, равного void, – clone (x) вернет void, а equal (x, y) вернет true, если и y - void.

Вызов процедуры copy в форме x.copy (y) не создает подобных проблем, поскольку требует непустых x и y. Это следствие семантики процедуры copy, копирующей поля одного объекта в поля другого, и имеющей смысл, только если существуют оба объекта. Как показано далее, такое условие для y фиксируется формальным предусловием copy, заданным в явном виде в документации.

Отметим, что введенная выше функция is_equal существует в библиотеке системы. Причина в том, что часто удобнее определить специфические варианты эквивалентности элементов конкретного класса, перекрыв семантику по умолчанию. Для достижения этого эффекта достаточно переопределить функцию is_equal в соответствующем классе. Функция equal определяется в терминах is_equal (выражением, показанным выше при иллюстрации использования is_equal), и поэтому следует за всеми переопределениями is_equal.

Когда есть функция clone, то нет необходимости в twin. Это связано с тем, что функция clone определена как создание объекта с последующим вызовом copy. Поэтому для адаптации clone к специфике класса достаточно переопределить процедуру copy данного класса. (См. также лекция 16)

Последние комментарии частично прояснили вопрос о статусе универсальных операций clone, copy, equal, is_equal, deep_clone, deep_equal.