>[оверквотинг удален]
> конкретных типов на этапе компиляции. И если это интересно, то я
> бы рекомендовал вообще посмотреть на borrow
> Для динамического полиморфизма придётся комбинировать это с &dyn Trait. То есть писать
> не функцию:
> fn foo<T: AsRef<BaseType>>(arg: T);
> а динамическую:
> fn foo(arg: &dyn BaseType);
> Примеров же реального применения я не знаю. Как правило, народ уворачивается от
> dyn Trait, в пользу статического диспатча.
> Тут речь не о презрении. На мой взгляд, заниматься разработкой и боятся компиляции -- это волков боятся в лес не ходить.На мой же взгляд компиляцию не всегда имеет смысл делать, и если делать её смысл не имеет, её лучше не делать
> Ну мне это удобно. Когда сорцы вот они здесь, тут, и я не понимаю что происходит, я всегда могу заглянуть туда.
Вытянуть и посмотреть сорцы и пересобрать мир - разные вещи.
> Это _теоретическое_ решение. Практически оно не работает из-за масштабов.
Отлично работает. Обновляю питоньи библиотеки из гита, убрав локи на версии, и ... ничего не ломается.
Ну прикинь, допустим мы всем разработчикам навтыкали пистонов, и они теперь как миленькие в темпе вальса обновляют свой код под все новые библиотеки. Но есть ненулевая вероятность того, что кто-нибудь из них всё равно не обновит -- потому что у него на работе завал из дедлайнов, потому что он в больнице лежит с запором, потому что жена не дала и он ушёл в запой. Список возможных причин можно продолжить.
Он не обновит - обновят другие. У популярных библиотек больше одного контрибьютера.
> Пускай эта вероятность 0.01, это значит, что при обновлении glibc, от которой зависят все пакеты debian'а, каждый сотый разработчик пропустит дедлайны на обновление своего пакета. И все пакеты которые зависят от этих пакетов тоже пропустят дедлайны.
Или хотя бы один из них пришлёт PR и либу пофиксят и дедлайны не пропустят. А если у популярной либы один мейнтейнер, который внезапно скончался, и теперь сливать PR некому, то срыв сроков всем сообществом вполне заслужен, раз они не смогли создать "организацию" и перевести репизиторий в коллективное управление.
> А у нас нет нужного количества чекистов и наганов? В реальности ситуация доходит до того, что невозможно создать систему, которая на всех распоследних версиях софта. Потому что когда мы дождались самых слоупоков из разработчиков, и закончили обновление пакетов, самые резкие разработчики уже успели выпустить новые версии своих пакетов, и может быть не по одной.
... которые совместимы со старыми версиями. Ещё раз - далеко не каждое изменение ломающее. Если бы хотя бы 25% изменений (каждый 4й мердж в мастер) были ломающими, мы бы тут все уже давно свихнулись бы.
> Всё что можно было бы сделать сейчас -- это собрать разработчиков всех сколь-нибудь популярных пакетных менагеров в кучу, пригласить так же и всех остальных интересующихся, и начать обсуждать общие для всех стандарты, так чтобы снизить остроту проблем возникающих из-за фрагментации.
ИМХО: проблема больше техническая. Все пакетные менеджеры делают примерно одно и то же: распаковывают архивы, раскидывают файлики по папкам, разрешают зависимости, создают симлинки, ведут базу данных, вызывают хуки, - значит проблема решается введением middleware, frontendов и backendов, где фронтэнды - это фактически переписанные поверх фреймворка пакетные менеджеры. Как LLVM, только для пакетных менеджеров. После запила и доведения до ума оригинальные пакетные менеджеры объявляются не нyжными и выкидываются на свалку истории.
Спасибо за дискуссию, про полиморфизм я так и не понял (и не нагуглил), как его запилить с помощью derefа.
