Недопустимость ссылок на подобъекты
Заключительное замечание ответит на вопрос, как сочетаются ссылки и подобъекты. Развернутый класс или развернутый тип, основанный на ссылочном классе, может иметь ссылочные атрибуты. Вполне допустимо, чтобы подобъект содержал ссылки на объекты, как показано на рисунке:
Рис. 8.21. Подобъект со ссылкой на другой объект
Приведенная ситуация предполагает следующие объявления:
Class COMPOSITE1 feature
other: SOME_TYPE
sub: expanded C
end
class C feature
ref: D
x: OTHER_TYPE; y: YET_ANOTHER_TYPE
end
class D feature
...
end
Каждый экземпляр класса COMPOSITE, такой как O_COMP на рис.8.21, имеет подобъект, (OC на рисунке) содержащий ссылку ref, которая может быть присоединена к объекту (OD на рисунке).
Но противоположная ситуация, где ссылка становится присоединенной к объекту, невозможна. Это будет следовать из правил присваивания и передаче аргументов, изучаемых в следующем разделе. Итак, структура времени выполнения никогда не может находиться в ситуации, показанной на рис.8.22, где OE содержит ссылку на OC, - подобъект O_CMP1, и OC содержит ссылку на себя.
Рис. 8.22. Ссылка на подобъект
Это правило открыто для критики, поскольку оно ограничивает моделирующие возможности подхода. Предыдущая версия нотации книги допускала ссылки на подобъекты. Но эта возможность порождала больше проблем, чем она того стоит:
[x]. С позиций реализации: механизм сборки мусора в этом случае должен быть готов справляться со ссылками на подобъекты, даже если в текущем выполнении будет всего несколько подобных ссылок или их вообще не будет. Это приводит к существенной потере производительности.
[x]. С позиций моделирования: ссылки на подобъекты заставляют отказаться от упрощения описания системы, что можно сделать, определив единственную ссылочную единицу - объект.
Присоединение: две семантики - ссылок и значений
В этом разделе рассматривается специальная информация, и он может быть пропущен при первом чтении.
Введение развернутых типов требует возвращения к рассмотрению двух фундаментальных операций, уже рассмотренных в этой лекции, - присваивания и сравнения. Так как сущности теперь могут обозначать объекты, а не только ссылки, следует точно определить, каков смысл присваивания и эквивалентности в первом из этих случаев.
Присоединение
Семантика присваивания, как отмечалось, распространяется еще на одну операцию - передачу аргумента при вызове подпрограмм. Предположим, существует подпрограмма (процедура или функция) в форме:
r (..., x: SOME_TYPE, ...)
Здесь сущность x это один из формальных аргументов r. Рассмотрим теперь некоторый вызов r в любой из двух возможных форм - квалифицированный или неквалифицированный вызов:
r (..., y, ...)
t.r (..., y, ...)
Выражение y является фактическим аргументом, передаваемым формальному аргументу x.
Выполнение r при любом из этих вызовов начинается с инициализации формальных аргументов значениями соответствующих фактических аргументов. Для простоты и согласованности правила, определяющие передачу аргументов, те же, что и правила присваивания. Другими словами, инициализация формального аргумента эквивалентна выполнению присваивания:
x := y
Это правило приводит к определению:
Определение: Присоединение
Присоединение y к x является результатом выполнения следующих двух операций:
Присваивания в форме x := y
Инициализации x при вызове подпрограммы, где x - формальный аргумент, а y - фактический аргумент вызова.
В обоих случаях x является целью присоединения, а y - источником.
Одни и те же правила действуют в обоих случаях для определения корректности присоединения (в зависимости от типов цели и источника). При условии корректности одни и те же правила определяют, каков будет эффект присоединения в период выполнения.
Присоединение: ссылочное и копии
При изучении ссылочного присваивания мы уже познакомились с эффектом присоединения. Если источник и цель являются ссылками, то эффект присваивания:
x := y
и соответствующей передачи аргументов состоит в том, что x получает значение ссылки y. Это иллюстрировалось несколькими примерами. Если значением y является void, то операция вместо присоединения сделает и x равным void; если y присоединен к объекту, то и x будет присоединен к этому же объекту.
Что происходит, когда типы x и y развернуты? Ссылочное присваивание не имеет смысла, а вот поверхностная форма копирования вполне возможна. Так и происходит. Рассмотрим объявления:
x, y: expanded SOME_CLASS
Присваивание x := y будет копировать каждое поле объекта, присоединенного к y, в соответствующие поля объекта, присоединенного к x, создавая тот же эффект, что и выполнение:
x.copy (y)
Копирование также является легальной операцией, эквивалентной в этом случае присваиванию. (В случае ссылок копирование и присваивание тоже легальны, но имеют разный эффект.)
Семантика копирования для развернутых типов дает ожидаемый эффект для всех базисных типов, которые, как отмечалось выше все относятся к развернутым типам. Например, если m и n типа INTEGER, то мы ожидаем от присваивания m := n, (или от соответствующей передачи аргументов) копирования значения n в m.
Проведенный анализ применим и к связанной с присваиванием операции эквивалентности. Рассмотрим булевы выражения: x = y и x /= y. Для x и y ссылочных типов, как уже отмечалось, истинность первого выражения (ложность второго) достигается только тогда, когда источник и цель оба имеют значение void или оба присоединены к одному и тому же объекту. Для развернутых x и y, такая семантика неприемлема, - здесь действует другая семантика, основанная на последовательном сравнении значений соответствующих полей, так что в этом случае выражение x = y имеет то же значение, что и equal (x, y).
| Разрешается, как мы увидим позже при обсуждении наследования, изменить семантику equal для придания специального смысла эквивалентности экземпляров некоторого класса. Это никак не отразится на операции эквивалентности =, которая по соображениям безопасности и простоты всегда имеет смысл оригинальной функции standard_equal. |