Согласен с Петром. Ресивер метода и параметр процедуры модуля не одно и то же.
А самое главное: VAR - это все же техническое решение изначально, а не концептуальное. Для указателей и записей интерпретация должна быть разной. Иначе будет каша как ни крути. Вообще все эти readonly, IN, OUT и соответствующая непростая семантика в CP, смахивают на попытки натянуть сову на глобус. Ну нету в оберонах концепции неизменяемых объектов! В оригинальном обероне VAR - это тупой модификатор для решения двух совершенно конкретных задач:
1) Изменение значения переданного в параметр внутри процедуры (иначе придется возвращать с копированием, плюс ко всему более одного значения вообще нельзя вернуть)
2) Избежание копирования больших значений при передаче параметром (ровно то, что в go решается указателем)
Насколько я понимаю Вирта, тут нет никакой идеи изменяемость/неизменяемость. Т.е. VAR - это не архитектурная плюшка, а что-то вроде директивы компиляции. Решение инженерное и вынужденное, но простое в реализации и использовании. И, кстати, это решение совершенно очевидное и неизбежное. Попробуйте ка придумать иначе! Вот, например, в go сделано иначе. Там на любое значение в любом месте можно получить указатель и делать с ним что хочешь. Вплоть до возврата из функции указателя на локальный рекорд. Где будет размещен при этом рекорд, решает компилятор. Сделано это ценой усложнения компилятора.
В CP внезапно VAR обретает новые смыслы и домыслы. Тут и там попытки решать сомнительные задачи в сомнительной модели архитектуры. Никакой сильной концепции все эти свистоперделки не несут, и конкретных проблем не решают (если не насасывать палец до посинения). Если хочется настоящих концепций про контроль доступа, то это в Rust. Или там в уровни изоляции транзакций в СУБД.
Вообще, имхо, методы нужно воспринимать как сообщения. Мы посылаем объекту сообщения, а как на них реагировать, решает сам объект. В идеале к кишкам объекта доступа быть вообще не должно, а все свои инварианты объект сохранит сам. И где тут приткнуть это самое readonly? Что оно дает?
На мой взгляд доступ для чтения может понадобиться только в одном случае: если нам лень писать методы для проверки состояния объекта, и мы хотим дать возможность читать это самое состояние напрямую. И тут вдруг нельзя вызывать методы... С какого перепугу?
Вы посмотрите на это с другой стороны. Модификатором "-" мы не запрещаем изменение, а разрешаем просмотр!
Разрешаем, а не запрещаем!