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

Вообще, можно совершенно строго (формально) вывести понятие интерфейса и доказать его... «односложность»... Можно... но не здесь.

По-моему, слишком много всего наворочено в нашей дискуссии вокруг интерфейса. Все много проще. Интерфейс -- это средство абстрагирования. Он устанавливается между двумя и более вещами (субъектами/объектами, уровнями/слоями и т.д. и т.п.).

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

Некорректно сравнение, а... вот сопоставление вполне даже... корректно. Сами же сказали, что «инструментарий для поддержки методологии»... И, наверное, полезно сопоставить инструмент и ту задачу (поддержки), которую он призван решать. Так что, все вполне корректно...

Для этого надо:
1. Четко сформулировать задачу
2. Указать ее ограничения
3. Если задача уже была ранее решена, рассмотреть альтернативные варианты (как другой инструмент того же класса эту задачу решает -- другой язык).

Простите, но этого сделано не было.

Здесь говорилось о несколько иной проблемной области...

Давайте конкретно -- назовите область и кто о ней говорил.

Зачем эти ухищрения при написании программ? Они нужны для построения чего существенно иного, для строительства программных сред, комплексов, систем... коими и является то же BlackBox и иже с ним. Правильно?

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

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

Теперь Вы говорите, что «подходы к "системостроительству" не зависят от языка программирования», но отстаиваете, что в язык (3GL) должны быть встроены средства «системостроительства»»...

Я такое, насколько помнится не говорил, но если надо -- скажу. Базовые средства (перечисленные мной выше) могут (а не должны!) быть встроены в язык. Если Вы обратили внимание, то я провожу границу между Обероном (к которому питаю несколько большую симпатию) и КП. Так вот, КП такими средствами обладает в большей мере, чем классический Оберон. И он лучше подходит для задач программной инженерии, чем Оберон. Здесь нет противоречий. Методология не должна знать о языке реализации, но при этом должна предусматривать наличие средств конкретизации (подходов к отображению методологии на конкретные парадигмы и языки реализации). Язык реализации может располагать средствами, содействующими:
1. Более адекватному отображению ее концепций.
2. Контролю и надежности такого отображения.

Выбор языка реализации диктуется:
1. Степенью адекватности отображения
2. Областью применения (требования реального времени могут выдвигаться в любой предметной области)
3. Условиями конкретного проекта (сроки, ресурсы, квалификация, требования к интеграции и т.д. и т.п.).

Соответственно для промышленного применения необходимо иметь несколько схем отображения методологии на конкретные языки реализации, чтобы обеспечить эффективную вариативность.

То, что с моей стороны говорилось о построении систем, конечно, было очень поверхностно, вдаваться глубже в рамках форума не имеет смысла, но все же... похоже многие прочувствовали, что построение системы – это не написание программы.

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

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

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

Развитие методик «системостроительства» не только исключит потребность в ухищрениях, но и серьезно сократит область применения 3GL, аналогично тому, как развитие 3GL сократило применение ассемблеров.

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

И время на изучение техник (a-la «квалифицированного импорта») будет просто потрачено не только впустую, но и со вредом (искажается нормальное восприятие задачи, преломляется через неподходящий для данной задачи инструмент).

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

P.S. Малая толика того, что я сейчас рассказываю, продумывалась и реализовывалась мной (и моими коллегами) в период 1985-1993 гг. Несмотря на чисто исследовательский характер, на этой основе делалась не одна "закрытая" система. Так что рассуждения носят отнюдь не умозрительный характер. Мне было что с чем сравнивать за последние годы, работая во флагмане постсоветского программирования (EPAM Systems) и имея доступ ко многим новейшим проработкам (как внутренним, так и внешним). К этому даже близко не подошли.

Ответ на »сообщение 4048« (AVC)
___________________________
IMHO, Слишком много эмоций с обеих сторон.
Увы... (но как иначе встряхнуть?..)

Уверен, что ASU не проводит по отношению к Оберону "враждебную политику". :)
Совершенно верно.

Вместе с тем, критика квалифицирующего импорта совершенно неубедительна.
ASU так и не указал альтернативный способ разрешения конфликта имен.
Хм?.. Если конфликт имен исключен, то какой еще нужен способ для разрешения несуществующих конфликтов?.. В начале 90-х мы разрабатывали проект СУБД (была тогда насущная проблема, нормальные транзакционные СУБД отсутствовали на персоналках, как класс...). Проект был весьма интересный. Во второй половине 90-х я попытался в FIDO выложить описание этого проекта для обсуждения... Там довольно хорошо были прописаны уровни (не все) и интерфейсы (и подходы к их проектированию)... Интерфейсов очень мало, они определяются одной структурой и конфликта быть не может... по определению. Другой пример. В теме «Семантическое моделирование» описан интерфейс позволяющий собирать систему управления предприятием из произвольного количества подсистем (правда, там не говорилось, что это интерфейс). Так он вообще один! Как он может конфликтовать сам с собой?.. Вообще, можно совершенно строго (формально) вывести понятие интерфейса и доказать его... «односложность»... Можно... но не здесь.

А главная мысль (что квалифицирующий импорт несовместим со "слабыми" связями) просто ошибочна (IMHO). Механизм совмещения был изложен в этой ветке многократно.
Жаль, но видимо я плохо объяснил... «Механизм» был описан через модули, но интерфейс должен быть определен на той стадии разработки, когда еще никаких модулей нет, и он должен поддерживаться на всех последующих стадиях, в том числе, на тех стадиях, где модулей и не должно быть. Это раз. Два и три... тоже были изложены.

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

Ответ на »сообщение 4025« (MS)
___________________________
С этим не ко мне... С моей точки зрения, есть четкая последовательность:
процедуры -> библиотеки -> модули -> объекты -> агрегаты -> системы...
и никаких "противоборств"...
Насколько принципиально наличие в этом ряду библиотек и объектов? И именно в этих местах?
см. http://www.alexus.ru/russian/articles.htm

Ответ на »сообщение 4044« (Руслан Богатырев)
___________________________
Подходы к "системостроительству" не зависят от языка программирования.
«Революция, о которой, так долго говорили большевики... свершилась! Ура! Товарищи!!!» :)

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

Один и тот же язык программирования может использоваться как язык макетирования, язык моделирования, язык спецификаций, язык проектирования, язык реализации, язык развертывания, язык эксплуатационной/операционной поддержки, но это не означает, что такой подход разумен и полезен в отношении конкретных условий (предметной области, предпочтений и квалификации исполнителей, условий проекта и т.п.).
Готов подписаться... (праздник сегодня... что ли?) :)

Инструментарий для поддержки методологии реализуется на языках программирования. Язык Оберон -- один из таких языков.
Золотые слова!..

Сопоставление языка программирования Оберон с методологиями некорректно.
Некорректно сравнение, а... вот сопоставление вполне даже... корректно. Сами же сказали, что «инструментарий для поддержки методологии»... И, наверное, полезно сопоставить инструмент и ту задачу (поддержки), которую он призван решать. Так что, все вполне корректно...

Эти тезисы инвариантны относительно Оберона. В упомянутом тексте можно сделать замену слова "Оберон" на название любого другого языка программирования. Смысл останется прежним.
О! Уже не не верил... но все же дождался!.. :)

Хорошо, теперь основываясь на сказанном выше, давайте порассуждаем. Пока речь шла о создании программ, то в рамках этих задач, классы языков Pascal, Modula, Oberon – действительно были в числе лучших императивных языков (с моей точки зрения... после ассемблера :) ). Но! Здесь говорилось о несколько иной проблемной области... Вспомните разговоры «о каркасах», о подгрузке модулей, о том же квалифицирующем импорте... Зачем эти ухищрения при написании программ? Они нужны для построения чего существенно иного, для строительства программных сред, комплексов, систем... коими и является то же BlackBox и иже с ним. Правильно? Теперь Вы говорите, что «подходы к "системостроительству" не зависят от языка программирования», но отстаиваете, что в язык (3GL) должны быть встроены средства «системостроительства»»... В таком случае, подходы начнут зависить от этого языка, их начнут насильно притягивать... независимо от нашего желания или нежелания. Не забывайте, что «не только гончар лепит кувшин, но и...». Дом строят не только, исходя из замысла архитектора, но с привязкой к технологии... а технология привязана к средствам... Это первое.
Второе. То, что с моей стороны говорилось о построении систем, конечно, было очень поверхностно, вдаваться глубже в рамках форума не имеет смысла, но все же... похоже многие прочувствовали, что построение системы – это не написание программы. Вы сказали очень точно: «Это понятие (архитектурные и инженерные принципы создания программных систем) более высокого уровня, чем язык программирования»). Казалось бы... «это понятие» требует и нового взгляда, и нового осмысления, и новых теоретических разработок, и, наконец, новых инструментов. А вместо этого нам говорят, что Оберон едва ли не идеальное средство для решения подобных задач... в нем так много удобных, полезных и надежных механизмов. Но даже, если данный «топор» легче, удобнее и безопаснее любых других «топоров»... все же, не стоит строить с его помощью здание... При таком строительстве ведущую роль играют другие инструменты (простите за не совсем удачную метафору, но думаю смысл понятен).
Третье. Развитие методик «системостроительства» не только исключит потребность в ухищрениях, но и серьезно сократит область применения 3GL, аналогично тому, как развитие 3GL сократило применение ассемблеров. И время на изучение техник (a-la «квалифицированного импорта») будет просто потрачено не только впустую, но и со вредом (искажается нормальное восприятие задачи, преломляется через неподходящий для данной задачи инструмент).

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

>>>В Обероне нет никакой необходимости добавлять новый механизм.

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

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

Ответ на »сообщение 4038« (Сергей Перовский)
___________________________

[

Виноват, С.Перовский и сам все понимает, конечно.
Только вопрос свелся к субъективности.
Реальной проблемы все-таки нет.
А простота есть.

Ответ на »сообщение 4038« (Сергей Перовский)
___________________________

Естественное желание, написать новый модуль С, который будет реализовывать оба интерфейса. Ан нет, будте добры внести исправления во все модули использующие А и В.

Напишите С, и заодно переделайте А и В в просто фасады для С. В худшем случае модули-клиенты придется перекомпилировать, но никаких исправлений не потребуется.

Ответ на »сообщение 4051« (Сергей Перовский)
___________________________

>>>ASU так и не указал альтернативный способ разрешения конфликта имен.
А я указал :)

А ASU не указал. :)
Неизвестно, совпадают ли ваши подходы.

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

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

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

А если бы поддерживался "неквалифицирующий" импорт как в Модуле-2
FROM Math IMPORT Sin;
Вас бы это устроило?

Ответ на »сообщение 4024« (Сергей Перовский)
___________________________

Оберон предполагает автоматическую сборку описания интерфейса по ГОТОВОЙ РЕАЛИЗАЦИИ - только звездочки поставить.
Тогда как описание интерфейса должно предшествовать разработке модуля.


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

Нет никакой проблемы. И отдельных интерфейсов не нужно.