OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Понедельник, 24 Сентябрь, 2018 19:07

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 16 ] 
Автор Сообщение
 Заголовок сообщения: Средства организации модулей
СообщениеДобавлено: Суббота, 27 Октябрь, 2007 18:07 

Зарегистрирован: Среда, 28 Февраль, 2007 00:08
Сообщения: 141
Откуда: Нижний Новгород
GUEST писал(а):
Руслан Богатырев писал(а):
Я не разделяю точку зрения Евгения Зуева по данному вопросу.

Очевидно размышления Евения Зуева лежали в области необходимости дополнительных средств организации модулей в связи с чем данное высказывание сомнительно.

Может я чего не понял, но доп. средства организации модулей, по-моему, нужны. Например, разрешение на межмодульное наследование реализации _только для ограниченного_ числа модулей (если уж приходится терпеть наличие такого наследования).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Re:
СообщениеДобавлено: Суббота, 27 Октябрь, 2007 20:41 
Аватара пользователя

Зарегистрирован: Суббота, 19 Ноябрь, 2005 15:59
Сообщения: 803
Откуда: Зеленоград
batyrmastyr писал(а):
Может я чего не понял, но доп. средства организации модулей, по-моему, нужны. Например, разрешение на межмодульное наследование реализации _только для ограниченного_ числа модулей (если уж приходится терпеть наличие такого наследования).


Ограничение на наследование реализации уже существует в Компонентном Паскале: LIMITED (еще проще -- отказ от использования EXTENSIBLE).
А вот ограничение возможности импорта конкретного модуля -- хорошая идея.
Наверное, ее можно реализовать примерно так: ввести, наряду с секцией IMPORT, секцию EXPORT, где должны быть перечислены модули, имеющие право импорта данного модуля. (Если секция EXPORT отсутствует, то модуль импортируется как обычно, без ограничений.)
Это в качестве "затравки", т.к. должны существовать лучшие решения.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 28 Октябрь, 2007 05:47 

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 7850
Откуда: Троицк, Москва
AVC писал(а):
Наверное, ее можно реализовать примерно так: ввести, наряду с секцией IMPORT, секцию EXPORT, где должны быть перечислены модули, имеющие право импорта данного модуля. (Если секция EXPORT отсутствует, то модуль импортируется как обычно, без ограничений.)
Это в качестве "затравки", т.к. должны существовать лучшие решения.


Почему "должны"?
Чем это решение плохо?

(Наклевывается отдельная тема... может, сразу и выделить?)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Средства организации модулей
СообщениеДобавлено: Воскресенье, 28 Октябрь, 2007 09:52 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8989
Откуда: Россия, Орёл
Выделил :-)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 28 Октябрь, 2007 12:54 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 992
info21 писал(а):
Почему "должны"?
Чем это решение плохо?
Это разные вопросы и ответы могут быть разные. Более общие, в том числе. В частности возможно и группирование модулей в структуры по выполняемой функции. Что-то подобное упоминалось Русланом Богатыревым в характеристиках прогнозируемого языка архитектурного уровня.
info21 писал(а):
(Наклевывается отдельная тема... может, сразу и выделить?)
Почему бы и нет. Но лучше если в её начале будет указываться какие цели она перед собой ставит. Имхо, тем кто такие предложения о переносе выдвигает.


Последний раз редактировалось Сергей Оборотов Понедельник, 29 Октябрь, 2007 06:13, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 28 Октябрь, 2007 13:06 
Аватара пользователя

Зарегистрирован: Суббота, 19 Ноябрь, 2005 15:59
Сообщения: 803
Откуда: Зеленоград
GUEST писал(а):
Почему бы и нет. Но лучше если в её начале будет указываться какие цели она перед собой ставит. Имхо, тем кто такие предложения выдвигает.


Например, может быть потребность в том, чтобы подсистема имела вспомогательные модули, доступные только в рамках этой подсистемы (кластера?).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 28 Октябрь, 2007 23:46 

Зарегистрирован: Среда, 28 Февраль, 2007 00:08
Сообщения: 141
Откуда: Нижний Новгород
AVC писал(а):
GUEST писал(а):
Почему бы и нет. Но лучше если в её начале будет указываться какие цели она перед собой ставит. Имхо, тем кто такие предложения выдвигает.


Например, может быть потребность в том, чтобы подсистема имела вспомогательные модули, доступные только в рамках этой подсистемы (кластера?).

Простейший пример - группа модулей наподобие Files-HostFiles чтобы HostFiles был доступен для импорта только модулю Files. И так ограничить группу Host-модулей, навроде Meta - <группа Host-Kernel модулей> причем интерфейсы модулей этой группы видят только Meta и они сами.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 29 Октябрь, 2007 00:02 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8989
Откуда: Россия, Орёл
batyrmastyr писал(а):
Простейший пример - группа модулей наподобие Files-HostFiles чтобы HostFiles был доступен для импорта только модулю Files

Кстати, Files не импортирует HostFiles. Модуль интерфейса не имеет права импортировать модуль реализации. Наоборот, модуль реализации импортирует интерфейс и суёт туда свои разъёмы....


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Средства организации модулей
СообщениеДобавлено: Понедельник, 29 Октябрь, 2007 07:32 

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 7850
Откуда: Троицк, Москва
Предложение:

Подсистемы образуют просто еще один уровень блочности (процедуры--модули--подсистемы).

Раз это замечено 8), то че колесо изобретать -- нужен только механизм "локальных переменных" для этого уровня блочности, т.е. сущности, видимые всюду в подсистеме, но невидимые вовне. Концептуальная простота и единообразие опять же.

Синтаксически, возникает проблемка, связанная принятым соглашением об именовании глобальных сущностей (модуль.сущность).

А в остальном можно думать об оформлении.
Конечно, хотелось бы (если возможно) не трогать сам язык.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Средства организации модулей
СообщениеДобавлено: Понедельник, 29 Октябрь, 2007 12:23 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
info21 писал(а):
Подсистемы образуют просто еще один уровень блочности


Снабдить модуль специальным атрибутом (например, INTERNAL) и сказать, что модуль помеченный этим атрибутом могут импортировать только модули из его подсистемы.

INTERNAL MODULE XxxYyyy;

(*...*)

END XxxYyy.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Средства организации модулей
СообщениеДобавлено: Понедельник, 29 Октябрь, 2007 12:56 

Зарегистрирован: Среда, 28 Февраль, 2007 00:08
Сообщения: 141
Откуда: Нижний Новгород
Сергей Губанов писал(а):
Снабдить модуль специальным атрибутом (например, INTERNAL) и сказать, что модуль помеченный этим атрибутом могут импортировать только модули из его подсистемы.

INTERNAL MODULE XxxYyyy;

(*...*)

END XxxYyy.

И наблюдаем то самое изменение языка которого очень не хотим. Причем это уже 3й вариант решения задачи в этой ветке (есть более ранняя) + вариант Руслана Богатырева + вариант языка Eiffel , очевидно, у каждого есть +/- и надо найти несколько неулучшаемых (т.е которым нельзя добавить + не добавив при этом - ) и потом уже серьезно думать какой лучше.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 29 Октябрь, 2007 13:02 

Зарегистрирован: Среда, 28 Февраль, 2007 00:08
Сообщения: 141
Откуда: Нижний Новгород
Илья Ермаков писал(а):
batyrmastyr писал(а):
Простейший пример - группа модулей наподобие Files-HostFiles чтобы HostFiles был доступен для импорта только модулю Files

Кстати, Files не импортирует HostFiles. Модуль интерфейса не имеет права импортировать модуль реализации. Наоборот, модуль реализации импортирует интерфейс и суёт туда свои разъёмы....

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Средства организации модулей
СообщениеДобавлено: Понедельник, 29 Октябрь, 2007 13:36 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
batyrmastyr писал(а):
И наблюдаем то самое изменение языка которого очень не хотим.


Разьве можно на уровне языка ввести некое средство, но не изменить сам язык?

На внеязыковом уровне INTERNAL модули давно есть - для таких модулей производитель не выдаёт символьных файлов, выдаёт только исполняемые.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Средства организации модулей
СообщениеДобавлено: Понедельник, 29 Октябрь, 2007 13:54 

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 7850
Откуда: Троицк, Москва
Сергей Губанов писал(а):
На внеязыковом уровне INTERNAL модули давно есть - для таких модулей производитель не выдаёт символьных файлов, выдаёт только исполняемые.


Ну, тогда, может, и нефиг дергаться...

Есть ли реальная проблема-то?

Когда будет, тогда и решение (само) появится.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Средства организации модулей
СообщениеДобавлено: Понедельник, 29 Октябрь, 2007 14:55 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4485
Откуда: Россия, Орёл
info21 писал(а):
Сергей Губанов писал(а):
На внеязыковом уровне INTERNAL модули давно есть - для таких модулей производитель не выдаёт символьных файлов, выдаёт только исполняемые.


Ну, тогда, может, и нефиг дергаться...

Есть ли реальная проблема-то?

Когда будет, тогда и решение (само) появится.
Производитель распространяет подсистему(ы) с исходными текстами и пишет в документации - модуль имеет приватный интерфейс.

Мне решение с INTERNAL нравится.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Средства организации модулей
СообщениеДобавлено: Понедельник, 29 Октябрь, 2007 16:08 

Зарегистрирован: Понедельник, 05 Июнь, 2006 09:49
Сообщения: 327
Откуда: Ленинград, Емельянов Алексей Николаевич
Мне кажется эту проблему лучше решать на уровне IDE. Ну, например, делаем некоторое средство, которое формирует список экспортируемых сущностей, так, чтобы методом перетаскивания можно было вставить в программу (с автоматическим изменением списка импорта в модуле). Соответственно запрещенные к экспорту модули - недоступны.
Добавляем пункт меню - "Согласовать экспорт/импорт", для поиска модулей у которых список импорта не согласован с "главным" списком. А после наработки практики применения можно будет говорить о "законодательных" мерах.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 16 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2018, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB