OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 14:21

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




Начать новую тему Ответить на тему  [ Сообщений: 33 ]  На страницу Пред.  1, 2

Нужен ли данный механизм (в графит-определении) в граф-языках сред, подобных PureBuilder?
Да, и точка (и объяснять не буду, почему :)) 33%  33%  [ 1 ]
Да, потому что (аргументация в посте) 0%  0%  [ 0 ]
Да, но с доработками (изложение в посте) 33%  33%  [ 1 ]
Нет, потому что (аргументация в посте) 33%  33%  [ 1 ]
Нужен, но принципиально другой (определение в посте) 0%  0%  [ 0 ]
Всего голосов : 3
Автор Сообщение
СообщениеДобавлено: Пятница, 11 Февраль, 2011 12:32 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Я так понял, что запрещена следующая ситуация:
Процедура X модуля А использует процедуру модуля Б, процедура модуля Б использует процедуру модуля В, а процедура модуля В использует процедуру Y модуля А. Здесь даже нет рекурсии!

Чем объясняется такой запрет? Насколько он важен? Сохраняет ли он актуальность для структурного редактора, который:
1. Берет на себя поддержание целостности и непротиворечивости программы, включая все ее модули?
2. Создает модули, в которые исполнимый код включается не непосредственно, а только в составе процедур/функций (т.е. само понятие модуля несколько иное, чем в Оберонах)?

Может быть, достаточно более слабого требования: к моменту использования всё должно быть определено, и это должно быть ясно при окончательной сборке программы?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 11 Февраль, 2011 19:46 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Это требование связано с тем, что нормальная структура системы должна разделяться на слои.
Т.е. вы должны иметь возможность взять отдельно каждый модуль нижнего уровня - и он будет самодостаточен.
Потом взять любой модуль второго слоя вместе с нужными ему модулями первого - и этот набор будет самодостаточен... И т.п. Т.е. слоёность структуры статических зависимостей.
Если не получается без циклических зависимостей, надо разделить какой-то модуль на части.

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

Сейчас это решается так.

Из незыблемо-важного здесь - только слоёная (DAG-овая) структура графа использования определений модулями.

А вот остальное (как быть с динамическими связями реализации, отделять ли понятия "модуль описаний" от "модуль реализации" и т.п.) , видимо, доступно для творческого переосмысления, т.к. Вы придумываете "сильно другую" систему.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 11 Февраль, 2011 19:48 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Сергей Прохоренко писал(а):
Может быть, достаточно более слабого требования: к моменту использования всё должно быть определено, и это должно быть ясно при окончательной сборке программы?


А вот представьте, что это такая же проблема на более высоком уровне, как и проблема GOTO.
Хорошо ли разрешать произвольные "макароны" связей?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 12 Февраль, 2011 08:52 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Сергей Прохоренко писал(а):
Выбирается только вариант. Каждый "подвариант" является вариантом. По каждому варианту можно посмотреть справку.
Понятно, это в пределах заранее составленного набора функциональностей-процедур для выбора. А как фиксируем, почему выбрали в каждом конкретном месте конкретного проекта для одних условий (м.б. неформально - т.е. это даже как SUBSTIFы не записано - только "для человека") один вариант из палитры, а для других условий - другой?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 12 Февраль, 2011 12:09 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Драконограф писал(а):
Сергей Прохоренко писал(а):
Выбирается только вариант. Каждый "подвариант" является вариантом. По каждому варианту можно посмотреть справку.
Понятно, это в пределах заранее составленного набора функциональностей-процедур для выбора. А как фиксируем, почему выбрали в каждом конкретном месте конкретного проекта для одних условий (м.б. неформально - т.е. это даже как SUBSTIFы не записано - только "для человека") один вариант из палитры, а для других условий - другой?


Обоснование можно дать в комментарии.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 12 Февраль, 2011 15:49 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Илья Ермаков писал(а):
Сергей Прохоренко писал(а):
Может быть, достаточно более слабого требования: к моменту использования всё должно быть определено, и это должно быть ясно при окончательной сборке программы?


А вот представьте, что это такая же проблема на более высоком уровне, как и проблема GOTO.
Хорошо ли разрешать произвольные "макароны" связей?


Спасибо! Исчерпывающие ответы. :D

Для PureBuilder я предполагаю следующий механизм:

Цитата:
Все модули и подсистемы группируются в слои, которым программист дает наименования. По умолчанию слоям даются наименования Crosscutting Concerns (самый нижний), Infrastructure, Data Access, Business Logic, Services, User Interface (самый верхний), которые можно изменить. Наименования слоев не используются в каких-либо составных идентификаторах в программе. Слои не могут быть вложенными друг в друга. Пустые слои можно удалять. Можно вставлять новые пустые слои сверху или снизу от выделенного произвольного слоя.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 12 Февраль, 2011 19:21 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Сергей Прохоренко писал(а):
Драконограф писал(а):
Сергей Прохоренко писал(а):
Выбирается только вариант. Каждый "подвариант" является вариантом. По каждому варианту можно посмотреть справку.
Понятно, это в пределах заранее составленного набора функциональностей-процедур для выбора. А как фиксируем, почему выбрали в каждом конкретном месте конкретного проекта для одних условий (м.б. неформально - т.е. это даже как SUBSTIFы не записано - только "для человека") один вариант из палитры, а для других условий - другой?


Обоснование можно дать в комментарии.
Неформальное (информатически) - да, конечно, имея в виду комментарий "по месту выбора" (собственно, больше и негде вроде :) ). Формальное - смотря по тому, только для человека оно или для редактора тоже. Для второго случая я и предлагаю особый атрибут выбора (чтобы всё-таки автоматизировать выбор).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 12 Февраль, 2011 19:23 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Сергей Прохоренко писал(а):
...
Для PureBuilder я предполагаю следующий механизм:

Цитата:
Все модули и подсистемы группируются в слои, которым программист дает наименования.
...
Интересно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 12 Февраль, 2011 20:59 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Сергей Прохоренко писал(а):
Для PureBuilder я предполагаю следующий механизм:


Да, явное выделение слоёв - это интересно.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 13 Февраль, 2011 00:15 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Драконограф писал(а):
Сергей Прохоренко писал(а):
Обоснование можно дать в комментарии.
Неформальное (информатически) - да, конечно, имея в виду комментарий "по месту выбора" (собственно, больше и негде вроде :) ). Формальное - смотря по тому, только для человека оно или для редактора тоже. Для второго случая я и предлагаю особый атрибут выбора (чтобы всё-таки автоматизировать выбор).


Не понимаю, как можно автоматизировать выбор. Вот, например, выбор между ассоциативным и обычным массивом - как это можно перепоручить компьютеру? Программирование - это всё-таки творческий процесс.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 13 Февраль, 2011 00:24 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Илья Ермаков писал(а):
Сергей Прохоренко писал(а):
Для PureBuilder я предполагаю следующий механизм:


Да, явное выделение слоёв - это интересно.

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


Это, конечно, трудоемкая штука - сделать такой структурный редактор. Но, во-первых, дело облегчается тем, что все объявления уже рассованы по таблицам, а не разбросаны по коду. Во-вторых, похожий механизм анализа зависимостей уже сделали в Microsoft Access (см. вкладку "Зависимости объектов"). Значит, это заведомо реализуемо. В-третьих, речь идет не о том, чтобы всю функциональность реализовать в первой версии, а о перспективе. :roll:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 13 Февраль, 2011 11:25 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Сергей Прохоренко писал(а):
Драконограф писал(а):
Сергей Прохоренко писал(а):
Обоснование можно дать в комментарии.
Неформальное (информатически) - да, конечно, имея в виду комментарий "по месту выбора" (собственно, больше и негде вроде :) ). Формальное - смотря по тому, только для человека оно или для редактора тоже. Для второго случая я и предлагаю особый атрибут выбора (чтобы всё-таки автоматизировать выбор).


Не понимаю, как можно автоматизировать выбор. Вот, например, выбор между ассоциативным и обычным массивом - как это можно перепоручить компьютеру? Программирование - это всё-таки творческий процесс.

Или имеется в виду выбор одного из перечисленных вариантов ответа на вопрос о причине выбора? Цель этого непонятна.
Не, ясное дело, я имею в виду, что правила выбора определяет человек :) иначе это не Область, а "оптимизирующий транслятор" получится :D Но записывает их не где-то "на манжетах" - а прямо в том же документе, где содержится то, из чего выбирать. В этом случае (как и Вы предложили), цель - запись правил в комментарий "по месту выбора" (кстати, и для этого тоже нужно создать "точку приложения" комментария - и это одна из ролей области).

Цель в случае, когда не ограничиваемся комментарием - зафиксировать именно правило, применение которого "можно перепоручить компьютеру". Как логвыражение от переменн<ой|ых> выбора, значени<е|я> котор<ой|ых> можно, в свою очередь, определять вручную - или формировать в зависимости от каких-то других величин (в т.ч. извлекаемых из других источников данных); в разных местах я это правило называл то "SUBSTIF" (отдавая дань ТЯП с английской лексикой :)), то "Осн?:".
И главное - это правило будет автоматически применяться везде, где определено (сочинителем), избавляя его от рутинного ручного переподставления фрагментов схем (с неизбежными ошибками). Ту же роль для текстов вариантов играют SUBSTEXT-правила (если они есть - то применяются одновременно).
    Так, в этом примере значение SUBSTIF-переменной ОднокрУпрПрив может вводиться вручную, а может - по результатам выбора из некоего каталога конкретной модели автоматизированного привода (которой в каталоге сопоставлен атрибут типа управления). Редактор читает значение атрибута, заносит в переменную - и зависимые элементы документа модифицируются автоматически (и тексты при трансляции формируются под сделанный выбор). Не правда ли, удобно?
Добавлю, что в графическом синтаксисе (подробно показанном на данный момент в этом примере) удобно и задавать сами правила, и контролировать их применение - чисто текстовая форма была бы для этого неудобна, и эргономический выигрыш от автоматической подстановки получился бы не слишком большим (и потому в её отношении Вы опять-таки правы, выступая против) - хотя возможность ошибки сочинителя всё равно была бы единократной (в правиле автоматической подстановки), а не многократной (в каждом месте ручной).

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Ещё о приложениях областей
СообщениеДобавлено: Пятница, 18 Февраль, 2011 06:00 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Вот такую вещь ещё стоит отметить. Проработка подстановок непосредственно выводит на обобщение содержания областей-вариантов до классов. Можно взять опять же этот пример. Вынесенная область с содержанием модели кнопки, по сути, намечает путь к реализации сказанного в /Поликарпова,Шалыто, с.68-69/.
Помимо того, область оказывается подходящим механизмом для повторного использования содержания при отсутствии механизма процедур. Это можно видеть в том же примере, т.к. Promela - как раз язык без процедур - притом не отвлечённый, а практический.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 33 ]  На страницу Пред.  1, 2

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


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

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


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

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