OberonCore https://forum.oberoncore.ru/ |
|
Механизм Область для визуально-структурного редактирования https://forum.oberoncore.ru/viewtopic.php?f=93&t=3242 |
Страница 2 из 2 |
Автор: | Сергей Прохоренко [ Пятница, 11 Февраль, 2011 12:32 ] |
Заголовок сообщения: | Re: Механизм Область для визуально-структурного редактирован |
Я так понял, что запрещена следующая ситуация: Процедура X модуля А использует процедуру модуля Б, процедура модуля Б использует процедуру модуля В, а процедура модуля В использует процедуру Y модуля А. Здесь даже нет рекурсии! Чем объясняется такой запрет? Насколько он важен? Сохраняет ли он актуальность для структурного редактора, который: 1. Берет на себя поддержание целостности и непротиворечивости программы, включая все ее модули? 2. Создает модули, в которые исполнимый код включается не непосредственно, а только в составе процедур/функций (т.е. само понятие модуля несколько иное, чем в Оберонах)? Может быть, достаточно более слабого требования: к моменту использования всё должно быть определено, и это должно быть ясно при окончательной сборке программы? |
Автор: | Илья Ермаков [ Пятница, 11 Февраль, 2011 19:46 ] |
Заголовок сообщения: | Re: Механизм Область для визуально-структурного редактирован |
Это требование связано с тем, что нормальная структура системы должна разделяться на слои. Т.е. вы должны иметь возможность взять отдельно каждый модуль нижнего уровня - и он будет самодостаточен. Потом взять любой модуль второго слоя вместе с нужными ему модулями первого - и этот набор будет самодостаточен... И т.п. Т.е. слоёность структуры статических зависимостей. Если не получается без циклических зависимостей, надо разделить какой-то модуль на части. Динамические связи могут быть циклическими. Например, интерфейс какой-то службы (абстрактный класс) описан в модуле А, который лежит в самом нижнем слое. Но конкретные реализации этого класса втыкаются сверху - и про их модули вообще никто не знает (ведь все знают только абстрактный интерфейс). Сейчас это решается так. Из незыблемо-важного здесь - только слоёная (DAG-овая) структура графа использования определений модулями. А вот остальное (как быть с динамическими связями реализации, отделять ли понятия "модуль описаний" от "модуль реализации" и т.п.) , видимо, доступно для творческого переосмысления, т.к. Вы придумываете "сильно другую" систему. |
Автор: | Илья Ермаков [ Пятница, 11 Февраль, 2011 19:48 ] |
Заголовок сообщения: | Re: Механизм Область для визуально-структурного редактирован |
Сергей Прохоренко писал(а): Может быть, достаточно более слабого требования: к моменту использования всё должно быть определено, и это должно быть ясно при окончательной сборке программы? А вот представьте, что это такая же проблема на более высоком уровне, как и проблема GOTO. Хорошо ли разрешать произвольные "макароны" связей? |
Автор: | Владислав Жаринов [ Суббота, 12 Февраль, 2011 08:52 ] |
Заголовок сообщения: | Re: Почему голосую "Да, но с доработками"? |
Сергей Прохоренко писал(а): Выбирается только вариант. Каждый "подвариант" является вариантом. По каждому варианту можно посмотреть справку. Понятно, это в пределах заранее составленного набора функциональностей-процедур для выбора. А как фиксируем, почему выбрали в каждом конкретном месте конкретного проекта для одних условий (м.б. неформально - т.е. это даже как SUBSTIFы не записано - только "для человека") один вариант из палитры, а для других условий - другой?
|
Автор: | Сергей Прохоренко [ Суббота, 12 Февраль, 2011 12:09 ] |
Заголовок сообщения: | Re: Почему голосую "Да, но с доработками"? |
Драконограф писал(а): Сергей Прохоренко писал(а): Выбирается только вариант. Каждый "подвариант" является вариантом. По каждому варианту можно посмотреть справку. Понятно, это в пределах заранее составленного набора функциональностей-процедур для выбора. А как фиксируем, почему выбрали в каждом конкретном месте конкретного проекта для одних условий (м.б. неформально - т.е. это даже как SUBSTIFы не записано - только "для человека") один вариант из палитры, а для других условий - другой?Обоснование можно дать в комментарии. |
Автор: | Сергей Прохоренко [ Суббота, 12 Февраль, 2011 15:49 ] |
Заголовок сообщения: | Re: Механизм Область для визуально-структурного редактирован |
Илья Ермаков писал(а): Сергей Прохоренко писал(а): Может быть, достаточно более слабого требования: к моменту использования всё должно быть определено, и это должно быть ясно при окончательной сборке программы? А вот представьте, что это такая же проблема на более высоком уровне, как и проблема GOTO. Хорошо ли разрешать произвольные "макароны" связей? Спасибо! Исчерпывающие ответы. Для PureBuilder я предполагаю следующий механизм: Цитата: Все модули и подсистемы группируются в слои, которым программист дает наименования. По умолчанию слоям даются наименования Crosscutting Concerns (самый нижний), Infrastructure, Data Access, Business Logic, Services, User Interface (самый верхний), которые можно изменить. Наименования слоев не используются в каких-либо составных идентификаторах в программе. Слои не могут быть вложенными друг в друга. Пустые слои можно удалять. Можно вставлять новые пустые слои сверху или снизу от выделенного произвольного слоя.
По умолчанию модуль/подсистема помещается в самый верхний из имеющихся слоев. Можно перемещать подсистемы и модули между слоями вниз или вверх с помощью мыши. Модули и подсистемы более нижних слоев не могут использовать никакие объекты модулей и подсистем более верхних слоев. Перемещение модуля/подсистемы в более нижний слой или импорт из других модулей констант, переменных, процедур/функций и иных объектов допускаются, если не нарушается это требование. В противном случае пользователю выдается подробное сообщение. |
Автор: | Владислав Жаринов [ Суббота, 12 Февраль, 2011 19:21 ] |
Заголовок сообщения: | Re: Почему голосую "Да, но с доработками"? |
Сергей Прохоренко писал(а): Драконограф писал(а): Сергей Прохоренко писал(а): Выбирается только вариант. Каждый "подвариант" является вариантом. По каждому варианту можно посмотреть справку. Понятно, это в пределах заранее составленного набора функциональностей-процедур для выбора. А как фиксируем, почему выбрали в каждом конкретном месте конкретного проекта для одних условий (м.б. неформально - т.е. это даже как SUBSTIFы не записано - только "для человека") один вариант из палитры, а для других условий - другой?Обоснование можно дать в комментарии. |
Автор: | Владислав Жаринов [ Суббота, 12 Февраль, 2011 19:23 ] |
Заголовок сообщения: | Re: Механизм Область для визуально-структурного редактирован |
Сергей Прохоренко писал(а): ... Интересно.
Для PureBuilder я предполагаю следующий механизм: Цитата: Все модули и подсистемы группируются в слои, которым программист дает наименования. ... |
Автор: | Илья Ермаков [ Суббота, 12 Февраль, 2011 20:59 ] |
Заголовок сообщения: | Re: Механизм Область для визуально-структурного редактирован |
Сергей Прохоренко писал(а): Для PureBuilder я предполагаю следующий механизм: Да, явное выделение слоёв - это интересно. Только Вам, ещё раз обращу внимание, потребуется сильно прокопать проблему связей "по понятиям" (кто какое описание статическое использует) и связей "по вызову" (кто чей код вызывает, с учётом всяких многокосвенных вызовов). |
Автор: | Сергей Прохоренко [ Воскресенье, 13 Февраль, 2011 00:15 ] |
Заголовок сообщения: | Re: Почему голосую "Да, но с доработками"? |
Драконограф писал(а): Сергей Прохоренко писал(а): Обоснование можно дать в комментарии. Неформальное (информатически) - да, конечно, имея в виду комментарий "по месту выбора" (собственно, больше и негде вроде ). Формальное - смотря по тому, только для человека оно или для редактора тоже. Для второго случая я и предлагаю особый атрибут выбора (чтобы всё-таки автоматизировать выбор).Не понимаю, как можно автоматизировать выбор. Вот, например, выбор между ассоциативным и обычным массивом - как это можно перепоручить компьютеру? Программирование - это всё-таки творческий процесс. Или имеется в виду выбор одного из перечисленных вариантов ответа на вопрос о причине выбора? Цель этого непонятна. |
Автор: | Сергей Прохоренко [ Воскресенье, 13 Февраль, 2011 00:24 ] |
Заголовок сообщения: | Re: Механизм Область для визуально-структурного редактирован |
Илья Ермаков писал(а): Сергей Прохоренко писал(а): Для PureBuilder я предполагаю следующий механизм: Да, явное выделение слоёв - это интересно. Только Вам, ещё раз обращу внимание, потребуется сильно прокопать проблему связей "по понятиям" (кто какое описание статическое использует) и связей "по вызову" (кто чей код вызывает, с учётом всяких многокосвенных вызовов). Это, конечно, трудоемкая штука - сделать такой структурный редактор. Но, во-первых, дело облегчается тем, что все объявления уже рассованы по таблицам, а не разбросаны по коду. Во-вторых, похожий механизм анализа зависимостей уже сделали в Microsoft Access (см. вкладку "Зависимости объектов"). Значит, это заведомо реализуемо. В-третьих, речь идет не о том, чтобы всю функциональность реализовать в первой версии, а о перспективе. |
Автор: | Владислав Жаринов [ Воскресенье, 13 Февраль, 2011 11:25 ] |
Заголовок сообщения: | Re: Почему голосую "Да, но с доработками"? |
Сергей Прохоренко писал(а): Драконограф писал(а): Сергей Прохоренко писал(а): Обоснование можно дать в комментарии. Неформальное (информатически) - да, конечно, имея в виду комментарий "по месту выбора" (собственно, больше и негде вроде ). Формальное - смотря по тому, только для человека оно или для редактора тоже. Для второго случая я и предлагаю особый атрибут выбора (чтобы всё-таки автоматизировать выбор).Не понимаю, как можно автоматизировать выбор. Вот, например, выбор между ассоциативным и обычным массивом - как это можно перепоручить компьютеру? Программирование - это всё-таки творческий процесс. Или имеется в виду выбор одного из перечисленных вариантов ответа на вопрос о причине выбора? Цель этого непонятна. Цель в случае, когда не ограничиваемся комментарием - зафиксировать именно правило, применение которого "можно перепоручить компьютеру". Как логвыражение от переменн<ой|ых> выбора, значени<е|я> котор<ой|ых> можно, в свою очередь, определять вручную - или формировать в зависимости от каких-то других величин (в т.ч. извлекаемых из других источников данных); в разных местах я это правило называл то "SUBSTIF" (отдавая дань ТЯП с английской лексикой ), то "Осн?:". И главное - это правило будет автоматически применяться везде, где определено (сочинителем), избавляя его от рутинного ручного переподставления фрагментов схем (с неизбежными ошибками). Ту же роль для текстов вариантов играют SUBSTEXT-правила (если они есть - то применяются одновременно).
Ну и из показанных примеров, надеюсь, очевидно, почему ситуация подобного рода преобразований оказывается жизненной |
Автор: | Владислав Жаринов [ Пятница, 18 Февраль, 2011 06:00 ] |
Заголовок сообщения: | Ещё о приложениях областей |
Вот такую вещь ещё стоит отметить. Проработка подстановок непосредственно выводит на обобщение содержания областей-вариантов до классов. Можно взять опять же этот пример. Вынесенная область с содержанием модели кнопки, по сути, намечает путь к реализации сказанного в /Поликарпова,Шалыто, с.68-69/. Помимо того, область оказывается подходящим механизмом для повторного использования содержания при отсутствии механизма процедур. Это можно видеть в том же примере, т.к. Promela - как раз язык без процедур - притом не отвлечённый, а практический. |
Страница 2 из 2 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |