Ты забыл добавить в начале топика слова «еще одно».

А так, на винфак быдло...

NIH!

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

Именно. А что есть лучше?

Для Ъ я и так все описал одним абзацем.

приложения надо правильно разрабатывать,
а не полагаться на yahoo-lib.1-2.011.33.beta1-pre.1-bis.so из пакета GlabalZOG-Super-tool-01.beta0434454534.rpm.

Enjoy ur umbrella.tiff

не хватает тега java и соответсвющего уточнения названия темы.

Ява тут не при чем, подход применим и к байткоду. Ява мне более интересна и если буду реализовывать механизм - начну с нее. Но при наличии большого интереса - предоставлю proof of concept для llvm и нативного кода.

А так, на винфак быдло...

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

Самофикс: не только к байткоду VM

Есть. Думать.

У тебя слишком узкое видение проблемы. Проблема DI/DC - она, хм, может претендовать на звание фундаментальной, а не специфичной для некоей среды/некоей платформы.

И ча ты придумал?

Для особо одаренных, поясняю одну из сторон проблемы на конкретном примере: ты пишешь приложение. Оно зависит от библиотек A и B. Они, в свою очередь зависят от двух разных версий библиотеки C. Тебе не повезло и версии C несовместимы либо по интерфейсам, либо по поведению.

Твои действия?

Использовать нормальные библиотеки, а не говно.

ок. поехали дальше у меня есть код, использующий метод Bar.Baz.foo из пакета Quz версии 0.0.1, я знаю что до следующией мажорной версии (0.1) код будет совместим, я собрал либу и радуюсь жизни. Тут автор Quz обнаружил, что в пакете критическая ошибка и поменял реализацию foo без изменения интерфейса, и ура, старый подход позволяет использовать новую версию Quz без каких-либо изменений и хаков, в отличии от..

А вообще подобный подход в Erlang предлагался, можешь поискать там за и против были расписаны подробно.

линкуем A с С и B с C статически

У тебя нет альтернатив (таких примеров множество), нужны обе.

лучше разупорина прими. И так всё везде работает, не надо трогать

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

Чё, правда?

То-то всякие enforcer'ы пишут для жабы, для винды придумывают SxS, потом отказываются от SxS, весь мир начинает все линковать статически, все таскают с собой все нужные рантаймы.

И все равно - нет-нет, да чо-нибудь скрэшится из-за неверно подгрузившейся зависимости.

Это надо было в девелопмент создавать.

Не программировать, очевидно?

идентифицировать по паре (имя, хэш от кода)

а хэш от исходников или скомпилированного кода?

для винды придумывают SxS, потом отказываются от SxS,

это всё от того, что пакетный менеджер не используют, он бы разруливал зависимости

весь мир начинает все линковать статически

не весь мир, а винда. В онтопике почти всё и так нормально работает

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

Да такие вкусные, что Яббл с Гуглем сломя голову побежали Маркеты создавать, МС, как самый медлительный ребенок, опомнилась несколько позже...

ПМ порешали проблему, пока дистры помещались на СД, а пакетная база на ДВД.

От бинарного кода/байткода очевидно.

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

Еще одна жертва НИИ Свиноводства. Пакетный менеджер НЕ решает проблему конвергенции. Особенно в случае бинарного дистрибутива.

Мавен вон - самый настоящий ПМ по сути. А толку?

Ну так

перенесите

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

ПМ тоже решили небольшие проблемы распространения софта в рамках одного дистро-клепателя.

На остальной угарный треш можно посмотреть на примере Зюзи и РХЕЛа, по количеству поломанных инсталяций с помощью сторонних реп.

ПМ- жрать из одного корыта, жат что насыпет кормящий.

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

От бинарного кода/байткода очевидно.

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

Что тогда? Запретить самостоятельную сборку из исходников и использовать только одну расово верную бинарную сборку, брать хэши для формирования зависимостей только от неё?

Вы демонстируете узкое неакадемичное мышление.

Вопрос о проблеме, причем проблеме связанной с разработкой, причем проблеме достаточно общей, а не абстрактной.

Меня ваши дискуссии просто достали уже, я уже не могу в них участие принимать, блин. Одна дискуссия упоительней другой, просто. Про маркет, блин Про какую-то хрень пакетный менеджер. Чё ты несешь-то вообще? Ты можешь заткнуться? Пакетный блин менеджер — решит проблему блин Чего, блин? Про что несешь? Вообще офонареть.

А ничего, что из одного и того же исходника можно сделать овер 100500 вариантов бинарного кода

А абсолютно ничего. Точно так же, как ничего, что из одного исходника можно сделать овер 100500 вариантов .so или исполнимого эльфа.

ты пишешь приложение. Оно зависит от библиотек A и B. Они, в свою очередь зависят от двух разных версий библиотеки C. Тебе не повезло и версии C несовместимы либо по интерфейсам, либо по поведению.

А ты сам-то как подружишь у себя в окружении эти A и B, чтобы собрать такого франкенштейна?

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

В моей схеме - франкенштейн соберется сам.

так хэш для задания зависимости откуда брать будем? Вот я написал программку X, она дёргает функцию F из библиотеки Y, откуда я беру хэш от F и откуда такой же хэш возьмётся у юзера, который скачает мою программку?

мммм... мммоо мо-мо-мо... модераторы!!!!
Поциент готов!

Ты про что тут рассказываешь? Про /devel?
так и ломись туда, там тебя спецы широкого профиля выслушают.

Мне не впились проблемы разработчика с его «компиляцией» свистопогремушки из доступных либ.

Меня, как потребителя, интересует доступность продукта этого разраба. И с этим проблемы. А раз проблемы, то нах такой продукт. Да, смотрю узко, в область которая мне интересна.

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

Самофикс: сущности из A использовали

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

Именно. Причем предлагаю концепцию несложного решения.

А если тебе по теме сказать нечего - промолчи, какое мне дело до твоих маркетов?

Речь идет именно о разработке, но поскольку тут вопрос не о том, что «у меня внутре куте происходят скрежеты и стуки» - запостил в толксы.

Backward compatibility, я так понимаю в слове на букву ж?

Вместо хеша я просто юзаю modification time по utc файла с модулем. Но все равно приложение работает по минимальной версии те если у тебя куча кода зависит от модуля А и совместимые старые версии этого кода не содержат нужного тебе апи то вынужден обновлять модуль А чтобы заюзать новые версии модулей с желаемым апи. Это подстегивает обновлять модули и не ломает существующие приложения. Под это дело пилится cvs http://bga.name/p/stm/readme.txt

Обратная совместимость какого рода? Если речь идет о жабе - то на уровне сорсов - с минимальными изменениями (заюзать класслодер). Возможен автоматический конвертер.

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

Если речь идет о других платформах-инструментах-средах - зависит от.

Но да, полностью автоматически BC, скорее всего, не получить.

Это подстегивает обновлять модули и не ломает существующие приложения.

В идеальном мире, где девочки какают цветочками.

Вместо хеша я просто юзаю modification time по utc файла с модулем.

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

В идеальном мире, где девочки какают цветочками.

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

P.S. мне показалось или я пропустил ответ на мой вопрос, про критический фикс не изменяющий интерфейса?

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

Щас укажу.

А вообще подобный подход в Erlang предлагался, можешь поискать там за и против были расписаны подробно.

Реквестирую конкретную ссылку. На эрланге писал, но вот именно такого - не видел.

На уровне уже загруженного кода - да, вроде так и будет. Но в момент загрузки может подгрузиться любая несовместимая дрянь.

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

Я так и невижу как ты собрался решать проблему A < B < C1, A < D < C2 при этом вот С1 и С2 не совместимы. Или значит A кастовать C2 в C1 или С1 в С2 чтобы B B и D подружить да и себе унифицировать и скоро это станет адом

Сказано же тебе - A использует свою версию кода C, B использует свою версию кода C. Вероятность протечки структур данных, конечно, есть - но она есть и в текущей схеме, и довольно-таки мала при опосредованной работе через абстрактные интерфейсы.

И абстрактные интерфейсы у тебя тоже вот так сразу совместимы. Да я реши что теперь у нас на выхопе у метода foo будет не Map а List и тепепь A будет кастовать в обе стороны со всеми последсвиями