Ответ на »сообщение 3900« (AVC)
___________________________
Никто не смотрит на квалифицирующий импорт через "розовые очки".
Как только Вы предложите лучший механизм, все сразу забудут о квалифицирующем импорте.
Уже предложил... Но перечитайте то, что говорилось в защиту квалифицирующего импорта, прежде чем... говорить, что «никто не смотрит»...

>>>Но взамен Вы предлагаете некий неопределенный механизм, с передачей всей ответственности системному загрузчику.
Кто сказал о всей ответственности загрузчика?..
Я так понял Вашу реплику из »сообщение 3882«:
«Слабые» связи не должны быть компетенцией языка разработки. Это задача системного линкера при статическом связывании или системного загрузчика при динамическом связывании.
Понятно. Виноват, эту мысль надо было раскрыть более полно. Для этого надо рассмотреть всю схему... сейчас нет времени, извините.

>> Замените его механизмом соответствия интерфейсу (безотносительно каких либо модулей реализующих этот интерфейс). Красивее, не правда ли?..

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

Вопрос: о соответствии какому интерфейсу Вы говорите?
Например, я говорю об экспорте модуля.
А что такое интерфейс "вообще"?
Декларация, более или менее подробная... Простой и частный случай интерфейса – заголовок подпрограммы. В случае систем... поболее будет.

>>Каких имен? Интерфейсов? Он проверяется в тот момент, когда декларируется любой новый интерфейс, а не тогда, когда выполняется реализация данного интерфейса.

Допустим, у меня есть процедура foo в модуле M1, и процедура foo в модуле M2.
Как должен решаться конфликт имен?
Система, которая использует данный интерфейс. Если система не специфицировала, то выбор передается неким установкам по умолчанию или... случаю. Вас же не удивит, если, например, выборка из одной и той же базы данных вернет записи в разном порядке, если Вы явно не указали ORDER BY в запросе.

PS. Наверное, имеет смысл еще раз подчеркнуть, что написание модулей и сборка системы - это разные задачи.

Ответ на »сообщение 3884« (ASU)
___________________________

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

Макроязык внутри Оберон?..

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

ЗЫ. Да, кстати, тот самый DLL-hell, который Вы, похоже, считаете правильным системным подходом, в Оберонах запрещён принципиально.

Ответ на »сообщение 3899« (AVC)
___________________________
>>>А одна из заповедей системного проектирования – инкапсулируйте! Оставляйте снаружи только интерфейсы. Да, собственно, это давно уже не новость...

Полностью согласен.
Ну, вот и хорошо!

Экспорт модуля и является его интерфейсом, а квалифицирующий импорт представляет из себя однозначное и безошибочное подключение к такому интерфейсу.
Стоп... К интерфейсу или к модулю, который декларирует и реализует этот интерфейс? Это совершенно разные вещи! Понимаете, интерфейс – это набор протоколов, соглашений, деклараций, одним словом. Он является основой для взаимодействия уровней, но он не принадлежит ни одному из уровней! А на каждом из уровней может быть множество разных или похожих модулей, которые содержат реализации этих интерфейсов (соглашений, протоколов). Так вот, соответствие интерфейсу не предполагает привязки ни к одному из модулей ни на одном из уровней.

Раздельная компиляция гарантирует межмодульный контроль типов (что есть далеко не во всех языках).
А зачем «межмодульный»? Пусть будет соответствие интерфейсу?.. Если плата расширения соответствует протоколу (интерфейсу) PCI-E, то ее можно вставить во множество материнских плат имеющих данный разъем. А вот если она будет соответствовать какой-то одной плате... то проку будет мало.

Это простая и ясная схема, лучшей на нынешний момент мне просто не известно. Если бы я был знаком с такой схемой, возможно, я предпочел бы ее.
Вон Илья сам делает... Да и мне постоянно приходится решать эти вопросы. Но я бы еще раз подчеркнул, что данная «схема» не должна иметь отношения к языку программирования. Нельзя создавать одновременно модуль и систему... Сие... дурной тон...

Ответ на »сообщение 3898« (Руслан Богатырев)
___________________________
Мне трудно поверить, что Вы не используете в своей деятельности языки программирования (не важно -- общеизвестные или собственные, доморощенные). Я обращаюсь к Вам с настоятельной просьбой прояснить мои сомнения и ответить на свой же вопрос о "системности" в отношении других языков.
Очень боюсь Вас расстроить, но... придется. Меня не интересует сравнение языков. Моя точка зрения весьма проста, что для создания систем, Оберон не лучше других языков, требующих указания импорта... (даже не важно, квалифицирующего или нет). И позиционирование Оберона, как языка системного программирования, совершенно необоснованно.

Ответ на »сообщение 3894« (Илья Ермаков)
___________________________
Одна из причин путаницы - опять-таки в терминах. И по этому поводу у нас с Вами недопонимание уже не первый раз.
Вы понимаете термин "системное программирование" как "программирование с применением системного подхода - системного анализа и системного проектирования".
Разумеется нет. Под системным программированием я понимаю реализацию программных систем, безотносительно их области применения.

Терминологически-то может оно и более верно (хотя первый и единственный раз такую трактовку я услышал от Вас)
Вы мне льстите... :)
но тогда термин "системное" вообще теряет смысл, ибо АБСОЛЮТНО ЛЮБОЕ серьезное программирование сегодня в этом случае можно назвать системным (противопоставляя "системное" – "кустарное").
Вполне могу с Вами согласиться... Действительно, сегодня создается много разных программных систем. Но потери смысла, увы, не вижу. Создание любых систем (и программные системы не исключение) основано на одних и тех же принципах, изложенных, в частности, в работах АА Богданова (Малиновскокого), Берталанфи и т.д..

Мы под системным программированием понимаем деятельность по созданию программных систем, решающих собственные нужды ИТ. Т.е. "машиностроение для ИТ-отрасли".
Мне такое деление кажется искусственным (надуманным).

В программной системе есть две ортогональных составляющих: 1) абстракции ПрО, выделенные на основе анализа 2) архитектурные конструкции системы, введенные при проектировании.
Вы думаете, что при создании, например, автомобиля... этого нет?

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

Поэтому и подчеркивается ориентированность Оберона на системное программирование - потому что язык заточен под выстраивание гибких и надежных архитектур, но может быть менее выразителен для прикладника, которому нужно отражать в программе все богатство абстракций его ПрО.
Сможете назвать отличия «системной» области (в Вашем понимании) от «прикладной»?.. Был бы признателен. Что касается гибкости и надежности... что ж перейдем к ним...

Меня немного удивляет непонимание того, что в системе могут быть два вида связей - и гибкие, и жесткие.
Хм... Чем меряете жесткость?.. :) Отличия, пожалуйста, приведите...

Из Ваших слов о том, как строить системы, складывается представление, что система должна представлять собой нечто амебообразное и гомоморфное... Или не так?
Это смотря с какой «колокольни»... Ваш организм, например, постоянно обновляет свои клетки? Он амебообразен? В автомобиле можно поменять практически любые детали, узлы, агрегаты... он какой при этом?

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

Надежная система должна иметь скелет, каркас, построенный на жестких связях - и предоставлять разъемы, точки подключения, на которые коммутируются гибкие связи. Как можно строить устойчивую систему только на гибких связях, лично я не представляю.
А если «каркас» перестает соответствовать условиям, то начинаем все сначала?..

В архитектуре IBM PC есть гибкие связи между материнской платой, процессором, устройствами, но сам процессор и сами устройства построены на жестких связях. А как иначе?
Иначе?.. Очень просто... Было время когда в один и тот же разъем материнской платы можно было вставить различные процессоры от трех разных производителей. И это было удобно. Да и сейчас в один разъем встают процессоры с совершенно разной архитектурой... Аналогично и устройства... снял (программные) перемычки и... количество конвейеров GPU удвоилось... Что во всем этом плохого? И если изготовители обеспечат еще большую гибкость, то - замечательно! Например, ведутся работы над многоядерными процессорами с подгружаемой системой команд. Представтье, что у Вас на компьютере сотни ядер... Если Вам нужны расчеты, то значительная часть ядер превращается в "сопроцессор", если нужна работа с графикой, то много ядер превращаются в GPU и т.д. Согласитесь, это удобнее, чем покупать много разных и мощных устройств, систем охлаждений к ним... иметь много разъемов и разбираться в деталях настройки каждой новой платы для каждой новой задачи...

Вот статический импорт и есть пример жесткой связи, на которой строится "скелет" системы. И при этом квалифицированный импорт - это безусловное благо.
Покажите мне это. Предположим, что модуль А отражал данные на экране с помощью модуля Б. Модуль Б умел рисовать прямоугольные формы и элементы управления. Таков каркас. Теперь я у себя реализую еще один модуль Б', и мой пользователь может выбирать более удобный интерфейс, безо всякой перекомпиляции (обращению к разработчику). А Ваш пользователь? Одни и те же расчеты могут делаться по разным методикам, я постепенно расширяю количество модулей, а пользователь сам решает, как ему считать. Что делает Ваш пользователь? Мой пользователь решает добавить новую подсистему к системе... берет и добавляет (поскольку, только он знает зачем ему это нужно). А Вы будете перестраивать каркас?

Каждая сущность в коде называется полным именем. Потому что нет просто процедуры Do и просто типа Type - они не "плавают" в пространстве, а предоставляются конкретным модулем.
Спрячьте Вашу сущность... за интерфейсом. Пусть система сама решает (в полном соответствии с ее собственной логикой), когда и каким модулем ей пользоваться. Откуда Ваш программист вообще знает, как будет использоваться написанный им модуль? Вернитесь к примеру с компьютером... Появлялись все новые задачи, которые пытались решать старыми «модулями»... Решались, но плохо... Появлялись новые «модули», которые вставлялись в «старые» разъемы... Совершенствовались интерфейсы... и т.д. Я не думаю, что создатели первых машин думали о... компьютерных играх.

1) "Кто выполняет переключение разъемов?"
Например, третий модуль-диспетчер. Один из таких диспетчеров - инициализационный модуль среды/приложения.
А он то откуда знает о логике данной конкретной системе? Кто пишет сам диспетчер и «инструкцию» для него? И почему речь идет только об инициализации? Подмена, добавление и удаление модулей могут происходить постоянно. Вы же не берете автомобиль к себе в постель... (я надеюсь)...

Подключение разъема может выполнить при своей загрузке в память сам модуль с реализацией, но эта схема хуже предыдущей, из-за децентрализации контроля за переключениями.
Эта схема не «хуже», она просто никуда не годиться.

2) "Почему квалифицированный импорт не мешает гибким связям?" - а почему он должен им мешать?
МЕШАЕТ! (у Вас «не» - лишнее). Если разработчик при написании модуля думает о том, что откуда взять, и это «жестко» пришьет, то это скорее монолит, чем система... Система состоит из элементов... Открытая система постоянно обменивается элементами с внешней средой...

Я буду ниже использовать термин "лицевой модуль", за неимением лучшего. Под этим я пониманию тот модуль, "фасад", через который клиенты работают с некоторым сервисом. А сам сервис реализуется другими модулями-реализациями, про которые лицевой модуль ничего не знает.
Это уже ближе, но это не язык Оберон, а Ваша реализация (возможно, вполне хорошая). Собственно, подобные работы свидетельствуют, как я понимаю, о том, что и Вам не хватает гибкости, не смотря на приверженность к жесткости... :)

Ответ на »сообщение 3890« (ASU)
___________________________

>>>Вопрос на засыпку: а как компилятор будет осуществлять межмодульный контроль типов до того как в дело вступит системный загрузчик?
А... вот... никак... и не будет. Не его это ума дело... Были в свое время линкеры... библиотекари... а сейчас "на все про все" осталось... F9. :)

Интересно, как компилятор будет генерировать код для сущности, чей тип неизвестен?
Линкеры и библиотекари "в свое время" никак указанную задачу не решали.
Памятником той эпохе являются "загадочные" ошибки в сишных программах и DLL-hell.
А в "волшебные кнопочки" я уже давно не верю. Кнопочка только запускает некий механизм, о нем и речь...

Ответ на »сообщение 3891« (ASU)
___________________________

В Обероне такой механизм есть.
Он Вам не нравится.
Стоп... Давайте не будем переходить границ. Мои замечания связаны не с механизмами, а с попытками представить в «розовом свете» квалифицирующий импорт (с позиций теории систем).

Никто не смотрит на квалифицирующий импорт через "розовые очки".
Как только Вы предложите лучший механизм, все сразу забудут о квалифицирующем импорте.

>>>Но взамен Вы предлагаете некий неопределенный механизм, с передачей всей ответственности системному загрузчику.
Кто сказал о всей ответственности загрузчика?..
Я так понял Вашу реплику из »сообщение 3882«:
«Слабые» связи не должны быть компетенцией языка разработки. Это задача системного линкера при статическом связывании или системного загрузчика при динамическом связывании.

Остаются неясными:
1) механизм межмодульного контроля типов (этим отличается раздельная компиляция от независимой);
Замените его механизмом соответствия интерфейсу (безотносительно каких либо модулей реализующих этот интерфейс). Красивее, не правда ли?..

Это мы уже проходили. Пока что неизменно выяснялось, что это чревато ошибками.
Вопрос: о соответствии какому интерфейсу Вы говорите?
Например, я говорю об экспорте модуля.
А что такое интерфейс "вообще"?

>>>2) механизм разрешения конфликта имен.
Каких имен? Интерфейсов? Он проверяется в тот момент, когда декларируется любой новый интерфейс, а не тогда, когда выполняется реализация данного интерфейса.

Допустим, у меня есть процедура foo в модуле M1, и процедура foo в модуле M2.
Как должен решаться конфликт имен?

Ответ на »сообщение 3889« (ASU)
___________________________

>>>А одна из заповедей системного проектирования – инкапсулируйте! Оставляйте снаружи только интерфейсы. Да, собственно, это давно уже не новость...

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

Ответ на »сообщение 3896« (ASU)
___________________________

Хм?.. А Вы не задумывались над... постановкой своей задачи?.. Через какой «язык» Вы способны увидеть здание?..

Простите, а через какой -- Вы? Похоже, мои опасения начинают оправдываться... Многоуважаемый ASU, я предполагаю, что задавая свой вопрос о поддержки системности в Обероне, Вы наверняка обладаете ответом на него для иных языков (отличных от Оберона). Мне трудно поверить, что Вы не используете в своей деятельности языки программирования (не важно -- общеизвестные или собственные, доморощенные). Я обращаюсь к Вам с настоятельной просьбой прояснить мои сомнения и ответить на свой же вопрос о "системности" в отношении других языков.

Здесь есть следующие варианты:
1. Таких языков, с Вашей точки зрения, вообще нет.
2. Такие языки имеются.

Если они имеются, но у Вас недостаточно опыта/квалификации в Оберонах (видимо именно поэтому Вы и обратились к нам за разъяснениями -- ведь не для целей же выявления нашей "дремучести" в отношении "системности"), то будьте добры, поясните на примерах других языков раскрытие понятия "системности" (в Вашем преломлении).

Слушаю Вас очень внимательно...

Ответ на »сообщение 3887« (ASU)
___________________________

Сильные связи в Обероне формируются декомпозицией на модули (выявление/формирование сущностей и разбиение сущностей по модулям-контейнерам).
== Что такое «разбиение сущностей по модулям-контейнерам». Вы можете разбить одну сущность на несколько модулей? Зачем?..

Поясняю. Из четырех возможных сущностей в Обероне, отличных от модуля (тип, константа, переменная, процедура), любая из них может быть размещена в одном и только одном модуле. Я это явно отмечал, говоря о "порте приписки". Разбиение сущностей на модули -- есть установление соответствия "сущность --> модуль" (сюръективное отображение, не инъективное!). 

В Обероне/КП в отличие от других ОО-языков класс оформляется как тип, поддерживающий расширение и инкапсулирование с методами. Для ряда задач не имеет смысл отождествлять инкапсулирование с информационным сокрытием (т.е. не устанавливать жесткий экран для обмена между "классами-коллегами"). Это так называемый принцип "No Paranoia Rule", сформулированный Клеменсом Шиперски (а ранее -- Ханспетером Мессенбеком). Иными словами, в одном модуле (устанавливающим экран видимости, информационное сокрытие) могут сосуществовать разные классы, которые имеют возможности общаться напрямую, без требования прохождения "паспортного контроля" экспорта-импорта.

Инкапсулирование и информационное сокрытие, IMHO, есть формирование т.н. сильных связей.

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