Книга: Основы объектно-ориентированного программирования
Правила о закрепленных типах
Правила о закрепленных типах
Теоретически ничто не мешает нам записать 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.
Оглавление книги
- Правила творческой лени
- 1.3. Правила подключения к компьютеру внешних устройств
- Правила именования файлов
- 2. Правила вывода Армстронга
- 3. Производные правила вывода
- Правила работы успешных продавцов в кризис
- ГЛАВА 5 Правила продажи и обслуживания
- 4.1.3. Правила безопасности
- 4.11.4. Правила "все кроме"
- Правила рекомендательного маркетинга
- Правила набора текста
- Правила ввода формул