Ответ на »сообщение 3193« (Илья Ермаков)
___________________________
>>>Я примеры с грузовиками тут приводил для чего - чтобы продемонстрировать нелогичность наследования реализации как факта... :-)
Пример нелогичного применения инструмента очень хорошо подходит для доказательства нелогичности инструмента :)
Прежде чем строить иерархию в которой появится грузовой автомобиль, необходимо ответить на ряд вопросов: для чего будем строить систему, какие задачи решать, каковы перспективы развития и т.д.
Объект "грузовик" из задачи оптимизации плана перевозок все равно невозможно использовать в задаче оптимизации переключения передач.
Нужно ли выделять двигатель и движитель в отдельные объекты, определяется характером задачи.
Мы опять с разных горок смотрим. Вы делаете нечто общеупотребительное, а я узкоспециализированное.
Делегирование вовсе не противоречит использованию наследования - это прекрасно совмещаемые приемы.

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

Ответ на »сообщение 3214« (Руслан Богатырев)
___________________________
Я надеюсь это интерлюдия, и код последует чуть попозже :))

Ответ на »сообщение 3211« (Jack Of Shadows)
___________________________

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

Будем отрываться еще дальше. Пора переходить на язык раба Эзопа, того самого, который, получив свободу, отправился к Крезу, а тот послал его в Дельфы, где Эзопа обвинили в святотатстве и свергли со скалы. На тему модулей -- несколько анекдотов и высказываний.

Про модули и их неповоротливость.

Саперы ходят медленно, но лучше их не обгонять.

Про ненужность модулей.

Любой корабль может быть минным тральщиком. Один раз.

Про модули и namespaces:

Hепpавда, что женщины не могyт хpанить тайнy. Пpосто нyжно помнить, что это -- нелегкая задача, и женщины обычно спpавляются с ней коллективно.

Про жалкие модули и высокие материи мэйнстрима.

Жили-были мыши и все их обижали. Как-то пошли они к мудрому филину и говорят:
-- Мудрый филин, помоги советом. Все нас обижают, коты разные, совы. Что нам делать?
Филин подумал и говорит:
-- А вы станьте ёжиками. У ёжиков иголки, их никто не обижает.
Мыши обрадовались и побежали домой. Но по дороге одна мышка сказала:
-- Как же мы станем ёжиками? -- и все побежали обратно, чтобы задать
этот вопрос мудрому филину.
Прибежав, они спросили:
-- Мудрый филин, а как же мы станем ёжиками?
И ответил филин:
- Ребята, вы меня ерундой не грузите. Я стратегией занимаюсь.

Ответ на »сообщение 3210« (Илья Ермаков)
___________________________

В модульной парадигме архитектура строится на основе отношений модулей.
Чего тут непонятного?

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

Так вот и непонятно.

Что есть модуль? По сути это единственный экземпляр финального класса, ни от кого не наследующего и никому не позволяющего себя унаследовать. Что, собственно, и представлено в так нелюбимых Вами языках семейства Си и в Эйффеле.

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

Если использование классов - объектно-ориентированное программирование, то использование модулей (без классов) - объектное программирование (был когда-то такой термин).

Ответ на »сообщение 3208« (Руслан Богатырев)
___________________________

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

А что там в Си такого декларативного (помимо очевидных деклараций сущностей)? И что там за элементы ФП?

Ну как же? 8-о

Да хотя бы те же указатели на функции как рудиментарный и неудобный способ организации функций высшего порядка и ленивых вычислений (элемент ФП).

Тернарная операция ?: - аналог выражения if-then-else из функциональных языков (не оператора, а именно выражения, возвращающего результат).

Урезанный pattern-matching с помощью оператора switсh (декларативный элемент).

Вот лямбда-абстракций нет, ну так ведь никто и не говорил, что Си - функциональный язык. Но элементы ФЯ имеет! :о))

Аналогично и Оберон (за исключением условной операции ?:)...

Ответ на »сообщение 3209« (Руслан Богатырев)
___________________________
Мы хотим элементы конструктора, чтобы можно было отвинтить-привинтить, разобрать-собрать, вынуть-вставить, а нам в ответ -- тут только паспортный контроль: сверяем имена со списками, а мертвые души али живые -- какая разница, откуда прибыли -- тоже не колышет. Главное, виза есть -- проходи.
Руслан, ваши цветастые аллегории уж совсем оторваны от какого то бы ни было сравнительного анализа возможностей модульных систем оберона и скажем того же хаскеля.
Давайте поближе к телу.
Приведите пример кода, и что он дает в обероне, чего нельзя получить скажем в дельфи. А хаскель мы уж как нибудь присобачим для сравнения после вашего примера.
Там и поговорим про вынуть-вставить :))

Ответ на »сообщение 3207« (Geniepro)
___________________________
Нет, я говорю именно не про разницу в реализации, а про разницу в использовании. У ФП есть набор своих рецептов для архитектуры ПО, модули там используются только в качестве элементов композиции.

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

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

В объектно-ориентированной парадигме архитектура строится на основе отношений классов (наследование, агрегация...).
В функциональной парадигме архитектура строится на основе отношений функций (вам виднее, какие они там бывают).
В модульной парадигме архитектура строится на основе отношений модулей.
Чего тут непонятного?

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

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

Для Хаскелла модули - всего лишь способ разграничить пространства имён и спрятать ненужные другим внутренние сущности. Те самые namespaces, только реализованные жёстко, как в Обероне, а не как в С++...

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

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

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

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

А что там в Си такого декларативного (помимо очевидных деклараций сущностей)? И что там за элементы ФП?

Ответ на »сообщение 3205« (Илья Ермаков)
___________________________

И модуль в Хаскеле и модуль в Обероне - это "две большие разницы". Потому что архитектурная нагрузка у них разная. Модуль же - это не просто единица упаковки функций и типов...

Мне кажется, Вы придаёте черезчур большое значение модульности.

Конечно, Хаскелл существенно отличается от Оберона. Потому и предназначение модулей в этих языках разное.

Для Хаскелла модули - всего лишь способ разграничить пространства имён и спрятать ненужные другим внутренние сущности. Те самые namespaces, только реализованные жёстко, как в Обероне, а не как в С++...

В Обероне же - ещё и способ хранения изменяемой информации, которая в Хаскелле на уровне модулей просто не существует. В Обероне модуль - по сути объект, как в Аде-83 (только урезанный).

Но разница эта всего лишь в назначении модулей, а не в их реализации. Да, в Хаскелле нет простого экспорта - весь экспорт только read-only, ну так экспорт read-write в Хаскелле просто невозможен, вот и всё... А в остальном всё реализовано практически также, как и в Обероне.