Основы объектно-ориентированного программирования
Правила о закрепленных типах
Теоретически ничто не мешает нам записать like anchor для самого элемента anchor как сущности закрепленного типа. Достаточно ввести правило, которое запрещало бы циклы в декларативных цепочках.
| Вначале закрепленные опорные элементы (anchored anchor) были запрещены, но это новое, более либеральное правило придает системе типов большую гибкость. |
Пусть T - тип anchor (текущий класс, если anchor есть Current). Тогда тип like anchor совместим как с самим собой, так и с T.
Обратное определение не симметрично: единственный тип, совместимый с like anchor, - это он сам. В частности, с ним не совместим тип T. Если бы следующий код был верен:
anchor, other: T; x: like anchor ... create other x := other -- предупреждение: ошибочное присваивание
то в порожденном классе, где anchor меняет свой тип на U, совместимый с T, но основанный на его потомке, сущности x был бы присвоен объект типа T, а не объект типа U или U-совместимого типа, что некорректно.
Будем говорить, что x опорно-эквивалентен y, если x есть y или имеет тип like z, где z по рекурсии опорно-эквивалентен y. Присваивания: x := anchor, anchor := x, как и присваивания опорно-эквивалентных (anchor-equivalent) элементов, конечно же, допустимы.
При закреплении формального параметра или результата, как в случае
r (other: like Current)
фактический параметр вызова, например, b в a.r(b), должен быть опорно-эквивалентен a.
