>> Написать метод deref(&self) -> &ParentType? Да надо.
> Спасибо за наводку, но я её правда не до конца ещё осознал.
> Не могли бы вы привести ссылку на обучающий материал, где этот
> трюк используется именно для нормального наследования и нормального полиморфизма?https://doc.rust-lang.org/book/ch15-02-deref.html
Там правда примеры с умными указателями, но это позволяет, например, иметь Vec, который -- динамический массив, и при этом расширение типа slice, который нединамический массив. Но это, я так подумал, статический полиморфизм. Чтобы его пользовать ещё неплохо было бы AsRef/AsMut освоить, чтобы передавать в функцию slice или Vec, или всё что угодно ещё, что может быть приведено к типу slice. Но вся типизация должна быть разрешена до конкретных типов на этапе компиляции. И если это интересно, то я бы рекомендовал вообще посмотреть на borrow
Для динамического полиморфизма придётся комбинировать это с &dyn Trait. То есть писать не функцию:
fn foo<T: AsRef<BaseType>>(arg: T);
а динамическую:
fn foo(arg: &dyn BaseType);
Примеров же реального применения я не знаю. Как правило, народ уворачивается от dyn Trait, в пользу статического диспатча.
>> Отказ от первого пня в пользу i7 не сделает из тебя потреблятелем. Так же как отказ от i7 в пользу первого пня не позволит тебе прекратить быть потреблятелем.
> Разумеется. Потому что потреблятель - это образ мыслей. Есть люди, считаюшие,
> что допустимо дискриминировать людей по наличию/отсутствию определённых вещей и что люди
> без определённых вещей достойны презрения. Я с этим в корне не
> согласен.
Тут речь не о презрении. На мой взгляд, заниматься разработкой и боятся компиляции -- это волков боятся в лес не ходить. За счёт чего при этом ты будешь снимать страх -- за счёт Ryzen'а на 64Гб оперативки или за счёт философского подхода к компиляции, идущей в бекграунде -- это уже не столь важно.
>> Не, просто у пропиерастов, как правило, нет опции пересобрать. Пересобрать gtk с assert'ами? Заинжектить код в gtk, чтобы посмотреть, что из этого выйдет? Отключить/подключить опциональные депендансы? Сменить версии библиотек, уйти от stable, уйти от unstable и поставить себе последний коммит из git репо, который даже тегом не помечен, и поэтому идентифицируется лишь хешом?
> В случае тяжёлых зависимостей я бы этого избегал настолько, насколько имеет смысл.
> В большинстве случаев пересборка мира ради возможности вставить отладочный вывод не
> оправдана. И тем более не имеет смысла заставлять всех разработчиков собирать
> все зависимости самостоятельно.
Ну мне это удобно. Когда сорцы вот они здесь, тут, и я не понимаю что происходит, я всегда могу заглянуть туда. Можно конечно и в браузере посмотреть -- в документации есть ссылки на сорцы, -- но это не всегда удобно.
>> Ну если в философию нырять, то да. Они все ущербны. dll-hell нерешённая проблема, а все попытки её решить -- костыли, а не решения.
> Да дело не в dll-hell, который решается описанным мною правилом использования последних
> версий для всего.
Это _теоретическое_ решение. Практически оно не работает из-за масштабов. Ну прикинь, допустим мы всем разработчикам навтыкали пистонов, и они теперь как миленькие в темпе вальса обновляют свой код под все новые библиотеки. Но есть ненулевая вероятность того, что кто-нибудь из них всё равно не обновит -- потому что у него на работе завал из дедлайнов, потому что он в больнице лежит с запором, потому что жена не дала и он ушёл в запой. Список возможных причин можно продолжить. Пускай эта вероятность 0.01, это значит, что при обновлении glibc, от которой зависят все пакеты debian'а, каждый сотый разработчик пропустит дедлайны на обновление своего пакета. И все пакеты которые зависят от этих пакетов тоже пропустят дедлайны. При наличии тысячи пакетов в системе, даже если рядом с каждым разработчиком стоит чекист с наганом, мы будем обновлять glibc месяц, два, а то и полгода, из-за всех этих депендансов.
А у нас нет нужного количества чекистов и наганов? В реальности ситуация доходит до того, что невозможно создать систему, которая на всех распоследних версиях софта. Потому что когда мы дождались самых слоупоков из разработчиков, и закончили обновление пакетов, самые резкие разработчики уже успели выпустить новые версии своих пакетов, и может быть не по одной.
> Проблема в бардаке и зоопарке, когда в системе
> несколько менеджеров, дублирующих функциональность друг друга, и одни пакеты в одном,
> а другие - в другом, а третьи - в третьем, и
> у каждого менеджера свои закидоны.
Эмм... а чё поделаешь? Вот у меня стоит emerge, cargo плюс emacs'овый пакетный менагер. Я ещё со времён когда Common Lisp'ом увлекался понял, что полагаться на системный пакетный менагер в плане вытягивания каких-то очень специфичных многих депендансов -- это пустое дело. Всё равно придётся собирать руками. Можно писать ebuild'ы. Но кто ж за ними следить будет? А если взять quicklisp или что-нибудь в этом роде, то -- хоп -- и всё установлено.
Если техническая проблема, называемая dll-hell. А есть социальная проблема -- как всех задействованных в создании dll-hell собрать и сорганизовать так, чтобы они, не слакая, следили бы за всеми пакетами, и чтобы при этом не надо было бы к каждому ставить по чекисту с наганом. Ну или если ставить, то где взять чекистов и наганы.
И вот тут начинается фрагментация, потому что в каких-то сообществах удобнее часто-часто обновлять всё, в каких-то редко, но метко, третьим надо multilib, четвёртые хотят релизиться только по вторникам нечётного числа, и нет никаких реалистичных правил, которые бы устроили всех. Так что фрагментация эта не только вредна, но и полезна: она позволяет разным сообществам иметь более подходящие им правила, вместо одних правил для всех, которые никому не подходят.
Растущие масштабы разработки СПО приводят к этой самой фрагментации. Она неизбежна. И как бы я не сочувствовал аутистичным асоциальным хакерам, которые создали себе нишку для существования, где они могли вести себя так, как им удобнее, и жить себе неплохо, а тут их начинают всякие мимопроходилы организовывать CoC'ами, я не могу не понимать при этом, что это неизбежно рано или поздно должно было бы случиться в процессе роста масштабов СПО как социального явления. Социум он вообще такой -- есть вещи, которые не нужны или не возникают или не проблема в группе из 10 человек, но которые становятся занозой в заднице, когда группа разрастается до 1000 или до миллиона.
Всё что можно было бы сделать сейчас -- это собрать разработчиков всех сколь-нибудь популярных пакетных менагеров в кучу, пригласить так же и всех остальных интересующихся, и начать обсуждать общие для всех стандарты, так чтобы снизить остроту проблем возникающих из-за фрагментации. Но эта такая штука, которой по идее должны были бы заняться debian и redhat, как ведущие дистры. Но redhat'у это не особо надо, а debian'у бы со своими внутренними проблемами разобраться бы.
О! Шигорин! Ты читаешь эту стену текста? У альта нет желания выйти на мировой уровень, проработав эту проблему теоретически, организовав конференцию, пригласив туда представителей redhat, debian, ..., разработчиков pip, gem, cargo, meson, ...? С тем чтобы решить проблемы поддержки пакетов и минимизировать по возможности дублирование работ, выполняемыми мейнтейнерами разных дистрибутивов и разработчиками софта (которые собирают гемы для руби или крейты для раста), упростить и стандартизовать общение между мейнтейнерами одного пакета из разных дистров и разработчиками этого пакет. То есть, я не знаю как это делается, но я уверен, что не так уж и сложно будет найти человека, который скажет что надо сделать до конференции (разработать демку платформы кооперации?), и как надо подойти к написанию приглашений (обязательно ли использовать гербовую бумагу, или можно на простой), обращаться ли к ним Dear sir or madam, или можно написать Hi, nigga. Причём у вас там в альте ведь должно быть достаточно людей, которые в теме и которые, в отличие от меня, могут не теоретически рассуждать о проблемах, но вполне конкретно, с конкретными примерами, со ссылками на списки рассылки и тд, и тп. Подготовить пяток докладов от Alt'а (продуманных, осмысленных, отрецензированных десятикратно, с красивыми содержательными презентациями и вообще демонстрирующих высокий профессионализм Alta, увлечённость СПО, и все прочие положительные качества тоже демонстрирующих (хипстерство, как открытость новым технологиям и новым идеям -- это положительное качество (это я на всякий случай))), объявить регистрацию любых других докладчиков, и надеятся на то, что их наберётся хотя бы часа на три-четыре докладов. Не факт что сработает, но мне кажется, что шансы есть. Особенно если не забыть про печеньки в перерыве. ... Хотя... санкции... они всё испортят, да? Или у вас нет эффективных менагеров, с шилом в заднице, которые подобные вопросы проворачивают на завтрак?
>> Да. Но вот у меня крутится сайт на rust'е -- я его
>> поднимал год назад под проведение психологического эксперимента. Он не нужен уже, но по инерции крутится. И если мне сейчас приспичит что-то там поменять, то я поменяю и пересоберу его, без того, чтобы нырять на несколько часов в код, обновляя его, обновляя все депендансы и всё остальное. Причём соберётся как http-сервер, так и websockets сервер, так и wasm модуль (ещё через emscripten собранный).
> Несколько часов на обновление используемого API в своём коде - как-то многовато.
Я этот код не видел год. Это значит надо сходу положить полчаса на чтение кода и выяснение того, как оно работает. Плюс у кода есть зависимости, обновление которых, может привести к непредсказуемым последствиям для моего кода. Планируя такое я бы не закладывал менее двух часов ни при каких обстоятельствах, как бы эффективный менагер с чекистом не кричали бы на меня, а вообще я бы закладывал бы на это время с утра и до обеда, с оговоркой, что возможно это затянется до вечера.
Впрочем если речь только об обновлении ради обновления и перехода на более новые версии пакетов, то до вечера не затянется. К обеду справлюсь, по-любому.
>> Это значит, что я могу не трогать сайт, откладывая все крупные изменения, собирая их в TODO лист, с тем чтобы если придёт время менять сайт, то я сделал бы это всё за раз.
>> Это хорошо звучит в теории, а на практике очень удобно иметь долю свободы, чтобы цикл разработки одной программы не был бы жёстко прибит гвоздями к циклу разработки другой программы.
> Не к циклу разработки, а к изменениям API, используемых в конкретной программе/библиотеке.
Выкатывание новых версий в серьёзных проектах делают по расписанию. Согласно циклу разработки, типа окно для принятия новых фичей, потом мы окно закрываем, вылизываем код, тестируем, и выкатываем релиз. Опять открываем окно для принятия новых фичей. В несерьёзных проектах это происходит менее предсказуемо, но это не упрощает жизнь зависимым проектам, а усложняет.
> И изменение нутра библиотеки зависимые от неё проекты скорее всего вообще
> не затронет.
Опять же, закон больших чисел. Скорее всего не затронет, это значит что с вероятностью 10% всё пройдёт гладко. А теперь у нас есть 100 пакетов в депендансах, и матожидание нам подсказывает, что с десятью пакетами не заладится. Опять же, когда у нас в депендансах awk, который не меняет своих API веками, мы можем быть спокойны, но когда у нас в депендансах gfx-rs, чьи авторы активно экспериментируют с разными подходами создания API для программирования видеокарт, которое одевается поверх OpenGL, DirectX, Vulkan, Metal, ..., и при этом не создаёт никаких накладных расходов в рантайме, то практически наверняка что-нибудь сломается, и может быть сломается так, что мы чинить будем неделю.
> Решит ли это проблему зоопарка тулчейнов?
В каком смысле "решит"? Тулчейны никуда не денутся уже, они плотно вошли в терминологию cargo и они там будут всегда. Но, с другой стороны, разные тулчейны могут использовать один и тот же llvm. Причём установленный системно, а не в $HOME. Теоретически они могут даже использовать один и тот же бинарь rustc, который будет уметь работать как nightly, как beta или как stable. Но я не знаю ничего о таких планах: разные версии rustc разрабатываются в разных ветках git. Сливать их в одну ветку перед релизом будет слишком заморочно и надеятся на это не приходится.
