OberonCore

Всё равно ведь внутри модуля, где объявллен метод, модификатор read-only не должен работать. Как же теперь быть, глобальные рекорды с методами потеряли смысл.

Пётр, можно пример, что ты имеешь в виду? Туго соображаю что-то )

https://gist.github.com/kpmy/b98d9ee2a0 ... 4296bce544

Допустим, я описал свой рекорд, который оборачивает обобщённый список, даёт полезные методы, конвертирует типы, проверяет значения, в общем, обычный такой рекорд. Список лежит внутри рекорда скрытый.

Экземпляр рекорда я разместил в модуле, в переменной objList, сделал её read-only, чтобы никто не заменил мне рекорд, но сам-то я имею право его менять, через официальные методы.

К тому же, методы объявлены внутри модуля ypkDetails, стало быть они имеют полный доступ к переменной objList, а тут выясняется, что больше нельзя вызывать VAR-методы на read-only объекте и менять значения внутри IN-метода.

Итак, вопрос, какую концепцию нарушает вызов метода рекорда для переменной типа ObjList, описанного рядом с рекордом? Мне кажется, никакую концепцию. Я защитил свой объект и свои данные сам, скрыв поле list.

Более того, в случае с read-only record её методы вообще не имеют смысла, ведь они не могут сменить состояние своего же объекта.

Такая вот коллизия. Я думаю, это всё из-за смелого трактования read-only режима переменной/параметра на внутреннее состояние статического объекта доступного по этой переменной.

А с чего ты взял, что имеешь право? )
Только если имеешь доступ полный к объекту.

Вот изнутри этого модуля, в Init каком-нибудь и т.п. - пожалуйста, дёргай за методы. У тебя изнутри модуля переменная, естественно, доступна полным образом.


Read-only методы имеют. Ну, в твоём примере This и Length сделай на IN.

Вот именно, здесь объект это переменная, а не мой объект со всем его содержимым. Так же, как в ситуации с readonly указателем.

Какой смысл, если никто ничего не добавит? А если сделать полный экспорт, то затереть список можно простым присвоением objList :=...

Почему никто ничего не добавит?



Ты выставил переменную на чтение - все смогут только читать, используя методы IN.
А ты изнутри модуля сможешь менять. Обеспечивая свою какую-то семантику, из которой только часть - модификация этой переменной.

А вызов связанной процедуры - это "изнутри модуля"?

А что будет после расширения записи? Где-то есть переменная с типом базовой записи, а в качестве значения в неё уложили расширенную запись. Сможет ли фактическая запись вызывать внутри себя процедуры базовой записи?

Что-то не нравится мне эта дискуссия.

Во-первых, нужен явный пример.

Во-вторых, система контроля в КП неплохо продумана, и вот так нахрапом что-то там менять -- лично я решительно протестую.

Ну Вы изнутри своего модуля имеете полный доступ к переменной, которая экспортирована у Вас только для чтения!
Соответственно, можете вызывать её методы на изменение спокойно.



Так расширенную запись Вы не уложите в качестве значения!
Расширенные могут адресоваться только по указателю либо по ссылке.

И из методов расширенной, где (VAR self), Вы сможете вызвать методы на изменение базовой.
А из методов, где (IN) - не сможете.

Всё нормально

Запросто уложу -- в параметр.

Стоит напомнить, что это средство называется supercall и в КП помечено на удаление из языка.

Сущность расширенной записи -- в незнании, с которым расширением мы работаем.

Если мы это знаем, то знаем и модуль, где нужный метод прописан.
А, значит, нет нужды прописывать его как метод, а достаточно -- как простую процедуру, и вызывать соответственно.

Тут мы упираемся в вопросы грамотного архитектурирования.

***

Сильно беспокоит в этой мутной дискуссии, что фокусы с переопределением семантики могут мотивироваться аргументами, опирающимися на "плохие практики".

Ну так я и указал - адресоваться по ссылке.
Но не укладываться в переменную.

Дискуссия начиналась конкретная относительно подсистемы Ypk. И дело не в supercall, а в том, что нельзя теперь переменную, экспортированную только для чтения, передавать в VAR параметр, где бы он не стоял, так как компилятор при этом теряет контроль над нетронутостью объекта во время компиляции.

Суть задачи, которую теперь запрещено решать.

Иван, проблема не в Ypk, а в изменении семантики. Именно в том, что "нельзя теперь". Меняется же не тестовый академический компилятор, а промышленный инструмент, который любят, в том числе, за его устойчивость во времени. Это же не PHP.

Илья предлагает разумным образом отказаться от представления этих функций как методов для таких случаев.

Существуют сомнения, что возможность передать переменную только для чтения как VAR параметр - это баг, что мол может просто существовать разная трактовка read-only параметров.

Однако все согласятся, что многие проверки безопасности данных в коде КП выполняются до компиляции. Так вот этот баг не позволял проверке полностью проходить. Так как, если переменная передается в виде VAR, то дальше уже требования к неизменности невозможно проверить. Так как формально это ведь будет уже не read-only переменная. Так что этот фикс очень правильный. Это всего одна строчка в компиляторе:
http://redmine.blackboxframework.org/pr ... a7ed/diff/
Но она делает проверку сохранности данных до компиляции корректной.

Это изменение сделает разработку только безопаснее. Ну и так как достаточно строгие требования, то исправить баг надо даже не смотря на то, что его наличие используется.

Мы тут все знаем, как сделать иначе. Вопрос, почему нельзя сделать так?
Вообще, я не уверен, что корректно относиться к receiver как к formal parameter. Параметр может быть у любой процедуры, а вот ресивер только у метода, который описан всегда рядом с типом, то есть всегда имеет доступ даже к скрытым переменным. И действительно, ресивер может быть объявлен как IN или VAR что гарантирует возможность контроля доступа к полям рекорда. Но этот IN/VAR это внутренние особенности поведения объекта. И хотя раньше это было сломано, хорошо, что сейчас починили.

Но при этом в условиях полного доступа метода к кишкам собственного ресивера обсуждаемое изменение фактически лишает смысла внутренний контроль доступа, а может даже и всю концепцию методов на статических записях.

То есть, я не понимаю, почему все тут решили, что доступ к рекорду извне и доступ из метода это одно и то же. Только потому, что увидели в компиляторе переход от rec.Method() к Method(rec)?

В Активном Обероне нельзя передать как VAR параметр импортированную сущность, если она экспортируется только для чтения. Её можно передать или по значению или как CONST.
Но методы у переменной-объекта, экспортированной только для чтения вызывать можно.