Автор Тема: Интерфейс модуля как отдельная сущность  (Прочитано 38829 раз)

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1955
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re: Интерфейс модуля как отдельная сущность
« Ответ #15 : Ноябрь 13, 2016, 09:24:29 pm »
Как, имея только интерфейс A, транслятору собрать модуль B с эффективным размещением локального массива s из элементов структур S неизвестного размера.
Ну, в общем, я дал ответ на этот вопрос. Делается исходник интерфейса, компилируется и получается символьный файл. Программист сможет получить из него интерфейс, а транслятор - полное описание всех структур. То есть, символьный файл - это и есть интерфейс.
Ваш вариант работает лишь, если интерфейс модуля неотделим от его реализации, как в оберонах.
В других языках, таких как ада или модула-2, при компиляции исходника интерфейса компилятору может быть просто недоступна реализация модуля, в котором записи доопределяются, например, в них добавляются приватные поля.
В этом случае ваш вариант просто не работает.
to iterate is human, to recurse, divine

Салат «рекурсия»: помидоры, огурцы, салат…

trurl

  • Full Member
  • ***
  • Сообщений: 133
    • Просмотр профиля
Re: Интерфейс модуля как отдельная сущность
« Ответ #16 : Ноябрь 15, 2016, 08:27:16 am »
Это в обероне все типы модулей слепили в один, чтобы не усложнять и не думать. В реальной жизни это не годится.
В реальной жизни вообще обходятся без модулей.

valexey_u

  • Hero Member
  • *****
  • Сообщений: 3013
    • Просмотр профиля
Re: Интерфейс модуля как отдельная сущность
« Ответ #17 : Ноябрь 15, 2016, 12:51:35 pm »
Это в обероне все типы модулей слепили в один, чтобы не усложнять и не думать. В реальной жизни это не годится.
В реальной жизни вообще обходятся без модулей.

Вовсе нет. Используютс повсеместно и под разными соусами.
Y = λf.(λx.f (x x)) (λx.f (x x))

Valery Solovey

  • Hero Member
  • *****
  • Сообщений: 509
    • Просмотр профиля
Re: Интерфейс модуля как отдельная сущность
« Ответ #18 : Ноябрь 15, 2016, 09:13:50 pm »
при компиляции исходника интерфейса компилятору может быть просто недоступна реализация модуля, в котором записи доопределяются, например, в них добавляются приватные поля.
Я потому и предложил компилировать исходник интерфейса, что в нём содержатся и скрытые поля.

Valery Solovey

  • Hero Member
  • *****
  • Сообщений: 509
    • Просмотр профиля
Re: Интерфейс модуля как отдельная сущность
« Ответ #19 : Ноябрь 15, 2016, 09:19:32 pm »
Ещё вариант - доопределять расширяемые типы на этапе компоновки. То есть, настоящие свои размеры тип узнает только после того, как ему предоставят реализацию интерфейса, который он импортировал.

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1955
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re: Интерфейс модуля как отдельная сущность
« Ответ #20 : Ноябрь 16, 2016, 04:48:07 am »
при компиляции исходника интерфейса компилятору может быть просто недоступна реализация модуля, в котором записи доопределяются, например, в них добавляются приватные поля.
Я потому и предложил компилировать исходник интерфейса, что в нём содержатся и скрытые поля.
Это может быть невозможно в виду несуществования реализации модуля на момент раздачи разработчикам необходимых интерфейсов.
to iterate is human, to recurse, divine

Салат «рекурсия»: помидоры, огурцы, салат…

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1955
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re: Интерфейс модуля как отдельная сущность
« Ответ #21 : Ноябрь 16, 2016, 04:48:58 am »
Ещё вариант - доопределять расширяемые типы на этапе компоновки. То есть, настоящие свои размеры тип узнает только после того, как ему предоставят реализацию интерфейса, который он импортировал.
Вот об этом варианте я и говорю, но для kkkk этот вариант неприемлем как слишком сложный, неоднопроходный...
to iterate is human, to recurse, divine

Салат «рекурсия»: помидоры, огурцы, салат…

kkkk

  • Full Member
  • ***
  • Сообщений: 135
    • Просмотр профиля
Re: Интерфейс модуля как отдельная сущность
« Ответ #22 : Ноябрь 16, 2016, 09:30:19 am »
Для удовлетворения любопытства было бы интересно узнать, такой вариант где-нибудь воплощён?

Valery Solovey

  • Hero Member
  • *****
  • Сообщений: 509
    • Просмотр профиля
Re: Интерфейс модуля как отдельная сущность
« Ответ #23 : Ноябрь 16, 2016, 08:05:13 pm »
Это может быть невозможно в виду несуществования реализации модуля на момент раздачи разработчикам необходимых интерфейсов.
Под абстрактные типы выделять память невозможно. Тип должен быть полностью реализован (то есть иметь полный набор полей). Но это не налагает необходимость использовать для компиляции весь реализованный модуль. Достаточно будет только интерфейса, если в нём будут все поля.

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

Valery Solovey

  • Hero Member
  • *****
  • Сообщений: 509
    • Просмотр профиля
Re: Интерфейс модуля как отдельная сущность
« Ответ #24 : Ноябрь 16, 2016, 08:09:57 pm »
Для удовлетворения любопытства было бы интересно узнать, такой вариант где-нибудь воплощён?
Конкретно в таком виде - нет, наверное. Но был же Juice. Чтобы это воплотить, нужно работать в том же ключе - отложить часть компоновки исходника на момент загрузки приложения.

Kemet

  • Hero Member
  • *****
  • Сообщений: 587
    • Просмотр профиля
Re: Интерфейс модуля как отдельная сущность
« Ответ #25 : Ноябрь 29, 2016, 04:20:18 am »
Кто-то считает это необходимым, кто-то - ненужным. Меня интересует техническая сторона, точней одна её деталь. Как эффективно совместить локальные записи и закрытые элементы. В идеале интерфейс не должен содержать информации о скрытых элементах записи, пусть и помеченных как скрытые. Это легко достигается в интерфейсе уведомительного характера, но составляет проблему в интерфейсе для компилятора, так так тогда полный размер записи становится неизвестным, что является препятствием для размещения на стеке.

Более или менее правильные намётки на решение я знаю, которое нужно даже не для этого, но оно довольно сложное. А какие костыли вам по душе?
Это сделано в Модуле-3

kkkk

  • Full Member
  • ***
  • Сообщений: 135
    • Просмотр профиля
Re: Интерфейс модуля как отдельная сущность
« Ответ #26 : Ноябрь 29, 2016, 10:58:04 am »
Можете немного осветить, как это сделано?

Kemet

  • Hero Member
  • *****
  • Сообщений: 587
    • Просмотр профиля
Re: Интерфейс модуля как отдельная сущность
« Ответ #27 : Ноябрь 30, 2016, 06:21:40 pm »
Есть "непрозрачные" типы. Интерфей к типу определяется в интерфейсных модулях, в обще случае, тип может иметь несколько интерфнйсов, которые могут находится в различгых интерфейсных модулях. Таким образом, клиент видит только то, что ему позволено в импортированном интерфейсе.
В модулях реализации тип "открывается" (REVEAL ) и соответственно, реализуется. Реализация также может быть "размазана" по нескольким модулям(файлам).
То есть это то, что в Шарпе назвали partial types (из Модулы-3 идею и позаимствовали).
При сборке тип в итоге должен быть полностью "открыт" и реализован.

kkkk

  • Full Member
  • ***
  • Сообщений: 135
    • Просмотр профиля
Re: Интерфейс модуля как отдельная сущность
« Ответ #28 : Ноябрь 30, 2016, 09:19:41 pm »
Как происходит компоновка модуля, собранного с использованием интерфейса и модуля, являющегося воплощением этого интерфейса, если модуль-клиент использовал недоопределённые записи в массиве, в статической памяти или в как компонент других записей?

Kemet

  • Hero Member
  • *****
  • Сообщений: 587
    • Просмотр профиля
Re: Интерфейс модуля как отдельная сущность
« Ответ #29 : Декабрь 01, 2016, 05:25:53 am »
Тип не может быть "недоопределен" - я же написал, что при сборке тип должен быть полностью открыт и реализован, поэтому его размер компилятору известен. Но, так как состав сборки определяетяс сборочным скриптом, то содержимое типа, конечно, может быть различным для разных платформ или режимов компиляции(отладка/релиз), но, тем не менее, тип должен быть полностью определен до момента его использования.