OberonCore

Можно пример?

Вот пример:



Какой-нить другой модуль:


Пардон, даже ThisObj не надо. С метапрограммированием (через RefObj..) я клал, когда вообще не хотел экспортировать (но тогда нужно, чтоб символьная информация была доступна).

Условие задачки подразумевает, что Блэкбокс менять нельзя. SYSTEM тоже плохо.

Anyone?

Set/Get процедуры?

Импорт?

Совсем нельзя, или компилятор и загрузчик всё-таки можно (с сохранением языка и интерфейсов)?

В чём, собственно, ограничение? В том, чтобы разрешить изменение переменной только модулю реализации, а всем остальным запретить. Но в КП нет ни абстрактных модулей, ни модулей реализации, ни прикладных модулей и т. д. Все модули равноправны (просто "модули") и связаны только отношениями импорта/экспорта (в той же Модуле-2, например, это не совсем так). Вобщем, у меня ответ пока остаётся тот же: задачка нерешабельна без изменения языка. Те же Get/Set-процедуры, которые предложил Димыч, каким образом будут разруливать ситуацию, какой такой модуль пытается изменить переменную? Ведь все модули равноправны, с точки зрения языка! Чудо можно было бы явить, используя метапрограммирование, как предложил Илья, но из примера явствует, что без SYSTEM пока никак. К тому же, я считаю, что хорошим стилем является использование метапрограммирования исключительно для целей отладки. Хотя, не настаиваю на этом.

У меня есть идейка, но её нужно додумать. Впрочем, если она и будет работать, то всё равно костыль. Единственный плюс - без изменения языка и каркаса.
P.S. Это, конечно же, касается вновь создаваемых модулей. Уже созданных и являющихся частью каркаса таким способом не ограничить.

…барабанная дробь…

та-да-да-дам!

"А теперь внимание! Правильный ответ!" (с)

Так и генерирует.
Кто такое предлагал?

Устал барабанщик?

Среди знатоков "Что? Где? Когда?" нет барабанщиков. А вот пианисты были, по-моему.

Да, есть много свидетельств, что занятия музыкой развивает мозг. В том числе у детей (3-4-5-6-7) через мелкую моторику.

По задаче.

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

Поскольку импорт задаётся на уровне языка, а последний указанных выше возможностей не предоставляет в силу своего определения, то переформулируем задачу: надо, чтобы использование функционала определённых модулей было ограниченным. То есть, импортировать модуль получится, но функционалом воспользоваться - уже нет. К сожалению, это костыль, но в силу формулировки задачи вряд ли можно надеяться на более элегантный подход. Каким способом пресекать попытки использовать "запрещённый" функционал? Я долго на эту тему не думал и взял первый попавшийся способ: ошибка периода исполнения (т.е., трап). Итак, требуется, чтобы при компиляции ошибки не выдавались, но при любой попытке обратиться к модулю, ограниченному на импорт, выдавалась ошибка периода исполнения.

Для этого потребуется специальный функционал, поскольку:
Во-первых, "импортёр" должен сообщить "ограниченному" о себе - представиться - а тот должен сообщать результаты своей работы. Частоиспользуемый подход в подобном случае - протокол взаимодействия.
Во-вторых, "ограниченный" должен каким-либо образом принимать или вычислять список разрешённых модулей.

Если для решения задачи реализовать специальный функционал внутри "ограниченного" модуля, то возможны как минимум следующий вариант:
1. Список разрешённых модулей задаётся жёстко в коде (крайний случай) или представляет собой все модули той же подсистемы, что и "ограниченный". Протокол. Модуль имеет абстрактную запись, которую "импортёр" реализует. Экземпляр записи передаётся в "ограниченный", который выполняет опознание (средствами Meta) и проверку. В зависимости от результатов проверки "импортёр" в конце концов получает или функционал, или трап.

В случае реализации специального функционала на отдельном уровне возможен как минимум следующий вариант:
1. Реализуется модуль, аналог Config, содержащий идентификатор "ограниченного" и список модулей для него. "Ограниченный" импортирует его для получения списка разрешённых модулей. Протокол может иметь вид как для предыдущего случая.

Ошибка периода исполнения. У окна трапа имеется заголовок, сообщающий причину возникновения ошибки. Полезно будет иметь заголовок вида "Запрещён доступ к импортируемому модулю".

В принципе, можно прошить работу с таблицами допустимого экспорта и HALT в случае недопустимого в модуль-загрузчик (StdLoader).

А каким образом мы обоснуем трап перед пользователем? Формально он ничего не нарушал. Импортировал переменную, доступную для записи, переписал её, ибац (С) - трап!

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

Ну вот, уже что-то похожее на решение наклевывается.

А зачем тут придумывать общее решение?

Когда будет ясно, чего нужно, можно конкретный разъём-хук и сделать.

Но надо же понять, что это за хук, и куда его вделывать.

Дело не в том, что можно писать в переменную, а в том, что у модуля есть процедуры, и надо ограничить доступ к их использованию.