Блин, у раста рили проблемы с диаем. @p0lunin у тебя

твой фреймворк рили работает? Если да то я мб попробовал бы его заюзать. Ты смог сделать скопед-депенденси на FromRequest?

Да. Я уже скидывал тебе пример. Если ещё будут вопросы или что-то непонятное - пиши. https://github.com/p0lunin/teloc/blob/master/examples/actix_example/src/services.rs#L39 вот пример конструктора который на вход получает &Method из scoped HttpRequest

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

а shaku не устраивает/пробовал?

не пробовал. В планах попробовать полунинскую поделку, но пока до раста руки не доходят

С teloc тоже хочу покапаться как-нибудь, но по беглому взгляду эксамплов/тестов - функциональных различий особо не вижу 🤔

Основное различие - добавление teloc в проект практически не требует никаких изменений в старом коде. Единственное что требуется - это навесить один макрос #[teloc::inject] на конструкторы для нужных типов, после чего создать одну структуру. Для rocket есть поддержка у shaku. На данный момент у teloc нет. Также при нежелании использовать dyn Trait в shaku придется писать вот такие портянки https://github.com/p0lunin/teloc/issues/8 Ну и в целом идеология teloc - как можно меньше макросов. По сути для полноценной работы необходим лишь один макрос. В shaku основа - динамические трейт-обжекты, там основной упор сделан на них, как в большинстве других диаев.

Ну в целом, почему большинство di полагаются на трейт-обжекты - довольно понятно. Как правило за счет DI я хочу также организовать хорошую инверсию зависимостей. Но сам подход к безболезненному внедрению в проект - мне нравится. Шаку обмазан слегка в этом плане.

И как я понимаю, интеграцию для актикса не получится так просто заюзать, если у меня роуты макросами actix’a обозначены (аля #[get("/some_resource”)] ). Поправь, если не так

Хм. Я и забыл про наличие такого макроса. Как будет время, попробую.

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

хм, гварды там можно навешивать точно, разве что это не всегда удобно

так ты же сам пилил под это дело крейт: https://t.me/rustlang_ru/351577 Не очень звучит как "можно навешивать" если пришлось это пилить

Там крейт немного для другого все же) Гвардом тоже можно навесить, просто когда гварды с кастомными параметрами например - действительно удобнее в коде

Жду когда можно будет писать макросы в стиле функций macro fn has_role(fun: Function) -> Function { expr! { fn $fun.name($fun.args) { check_role(); $fun.call($fun.args); } } } Вот что-то такое было бы бомбой

https://github.com/rust-lang/rfcs/blob/master/text/1584-macros.md

чем это отличается от того что щас есть?

Тем что щас такого нет)

Не. Это опять же - макросы над token tree. Хочу макросы над внутренним представлением.

насколько внутренним? syn повыше чем токены

Настолько, чтобы знать конечные типы, методы, реализуемые трейты и т.п.

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

кажется, с multi stage можно такое делать, в духе http://okmij.org/ftp/ML/MetaOCaml.html

не курицы и яйца, циклов-то у тебя не будет. А так да, у тебя вывод может зависеть от чего-то

Выплевывать экспанд всех макросов сначала, а только потом чекать типы конечно