IMHO из мне знакомых модульная система хорошо организована в Erlang и Java. Т.к. в обоих случаях виртуальная машина загружает модули во время исполнения или запуска без предлинковки.

Ocaml или SML.

Плюсадин. Самая продвинутая, пожалуй, из всех.

perl

Smalltalk жеж

Ок, предлагаю участникам акции добавлять ответ на вопрос «why?».

OSGi же, ну!

Удобство: разруливает любые зависимости и версии jar-ников (бандлов).

Haskell, Racket?

python

Haskell: списки экспорта, импорта, переименование при импорте, возможность принудительной квалификации

Python - система импорта настраивается под собственные нужды (можно __import__ переписать;-)). Когда то я ее настроил так, что при сериализации данных (через pickle) импортированные модули автоматом загонялись под CVS, а при обратной сериализации из под CVS доставались нужные версии, включая зависимости с нужными версиями. Но оказалось не оч удобно, т.к. все ошибки сохранялись в т.ч.;-)

Python - система импорта настраивается под собственные нужды (можно __import__ переписать;-)). Когда то я ее настроил так, что при сериализации данных (через pickle) импортированные модули автоматом загонялись под CVS, а при обратной сериализации из под CVS доставались нужные версии, включая зависимости с нужными версиями

Больше шаманов хороших и разных. Чем менее предсказуемо поведение стандартных конструкций, тем лучше.

Вот классика жанра.

#define TRUE FALSE //Удачной отладки!

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

А мне определенно понравились модули в обероне

Я нигде не говорил лучше/хуже - эти понятия вообще применимы только в контексте конкретной задачи. Что лучше, литр коньяка или 10л воды?

ТС хотел расширить кругозор и приобрести интересный опыт - вот я ему и описал пример.

int _BUGAGA=0;
#define TRUE (_BUGAGA=!_BUGAGA,_BUGAGA)
#define FALSE (_BUGAGA=!_BUGAGA,!_BUGAGA)
//Не используйте макросы без нужды, и с головой будет все в порядке!

>ТС хотел расширить кругозор и приобрести интересный опыт - вот я ему и описал пример.

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

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

>Я, сударь, никому и ничего доказывать не хочу...

А вот это что -

Вообще гибкость и фичастость, это не всегда хорошо.

Это плохо _только тогда_, когда это противоречит ТЗ. Во всех остальных случаях «гибкость и фичастость, это не всегда хорошо» - подсознательные страхи сильно в детстве перепуганных...

> А вот это что

Вообще гибкость и фичастость, это не всегда хорошо.

Это говорил не я, а pathfinder.

ИМНО гибкость и фичастость всегда имеет как плюсы так и минусы. От задачи зависит, от задачи...

>Это говорил не я, а pathfinder.

ООПС... =) Сорри, маху дал...

ТС хотел расширить кругозор и приобрести интересный опыт - вот я ему и описал пример.

А я указал на то, что ты плохому учишь.

Гы... и спросила кроха - что такое хорошо и что такое плохо?

Меня глубоко умиляет этот ЛОРовский обычай - говорить что есть хорошо и что есть плохо (хотя вроде никто говорящего об этом и не спрашивал), о каких то решениях вообще БЕЗ АНАЛИЗА ЗАДАЧ, В КОТОРОЙ РЕШЕНИЯ ПРИМЕНЯЛИСЬ.

- Микроскоп это плохо!
- Для чего плохо?
- Плохо! Молоток гораздо ухватистей!
- Да мы в микроскоп на инфузорий сморим...
- Нет, молоток гораздо удобней!

Ноу коммент.

> Да мы в микроскоп на инфузорий сморим...

инфузории - фигня, радиолярии намного лучше

Слишком много метафор

Меня глубоко умиляет этот ЛОРовский обычай - говорить что есть хорошо и что есть плохо

Это не чисто ЛОРовский обычай.

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

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

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

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

> Сможете привести хороший, убедительный пример задачи, когда переопределение __import__ - удачная мысль?

Например при организации песочницы. Чтобы запретить загружать что-либо. Но в питоне с этим не очень.

Пожалуйста. Необходимо создать библиотеку, обеспечивающую кроме сохранения сериализованных данных сохранение исходных кодов всех задействованных модулей

Я не силен в питоне, это разве нельзя сделать через интроспекцию?

Например при организации песочницы. Чтобы запретить загружать что-либо. Но в питоне с этим не очень.

Песочницу вроде в питоне не сделать, __import__ можно в любой момент перебить.

Уффф... в пикле польз. класс хранится как имя класса и имя модуля. Что бы поднимать это дело надо версию модуля впихивать в имя модуля (при сохранении), и потом при загрузке на основе имени модуля вычислять и загружать нужный модуль. Я другого варианта кроме как через перегрузку импорта не знаю.

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

Другая задача - поглядеть кто кого импортирует, когда модулей много и есть кольцевые зависимости там довольно неочевидно что в каком порядке грузится. Свой импорт позволяет смотреть такие вещи оч. детально.

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

Так что тут вопрос тока в воображении...

Ох. Что-то мне лень вникать в теорию, как оно все там работает в питоне. Задам тогда последний вопрос. Предположим, что надо использовать две технологии, базирующиеся на использовании __import__. Причем каждая из них не должна знать о другой. Пускай это будет сериализация пользовательских классов и просмотр «кто, кого импортирует». Как они будут работать вместе?

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

Если технологии взаимоисключающие - то никак не будут работать, чудес то не бывает.