LINUX.ORG.RU

[Module system] Что-нибудь эдакое.


0

1

В разных языках есть разные модульные системы. Некоторые вшиты в язык, в некоторых нет (как в Lua, или JS). В некоторых можно загружать модуль в рантайме по произвольному имени/пути, в некоторых нет.

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

UPD: Ну и поясните в чём удобство.

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

olegk ★★ ()
Ответ на: комментарий от Begemoth

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

dmsh ()
Ответ на: комментарий от yoghurt

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

vladimir-vg ★★ ()

OSGi же, ну!

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

iZEN ★★★★★ ()

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

unC0Rr ★★★★★ ()

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

AIv ★★★★★ ()
Ответ на: комментарий от AIv

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

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

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

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

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

pathfinder ★★★ ()

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

yaws ()
Ответ на: комментарий от pathfinder

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

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

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

AIv ★★★★★ ()
Ответ на: комментарий от AIv

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

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

yyk ★★★★★ ()
Ответ на: комментарий от yyk

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

AIv ★★★★★ ()
Ответ на: комментарий от AIv

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

А вот это что -

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


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

yyk ★★★★★ ()
Ответ на: комментарий от yyk

> А вот это что

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

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

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

AIv ★★★★★ ()
Ответ на: комментарий от AIv

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

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

yyk ★★★★★ ()
Ответ на: комментарий от AIv

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

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

pathfinder ★★★ ()
Ответ на: комментарий от pathfinder

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

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

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

Ноу коммент.

AIv ★★★★★ ()
Ответ на: комментарий от AIv

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

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

aho ()
Ответ на: комментарий от AIv

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

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

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

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

pathfinder ★★★ ()
Ответ на: Слишком много метафор от pathfinder

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

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

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

AIv ★★★★★ ()
Ответ на: Слишком много метафор от pathfinder

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

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

vladimir-vg ★★ ()
Ответ на: комментарий от AIv

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

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

pathfinder ★★★ ()
Ответ на: комментарий от vladimir-vg

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

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

pathfinder ★★★ ()
Ответ на: комментарий от pathfinder

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

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

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

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

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

AIv ★★★★★ ()
Ответ на: комментарий от AIv

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

pathfinder ★★★ ()
Ответ на: комментарий от pathfinder

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

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

AIv ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.