Ну да

Спека самих esm давно готовп, а про ноду уже тоже в tc39 все обсудили вроде

Тянули из-за идеи кастомности резолва

Не знаю чем там кончилось

Владимир Курчаткин даже poc версию делал с esm

Ладно, не суть

Нормальная модульная система в расте сейчас: у каждого crate есть свой корень, можно запрашивать модули относительно текущего и относительно корня.

Т.е. нет проблемы "../../.." и нет проблемы одного корня, как с NODE_PATH

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

А, ну можно use менять вместо mod

Ну это клево да

И будет проверка и т.д. Т.е. DI на уровне модулей можно запилить как замену use перед компиляцией

Но опять же, был бы кастомный резолв)

Причем на уровне модуля да

NODE_PATH не самое удобное

Надо что-то уровня файла с одной функцией

String -> String

Мб еще context нужен

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

Тянули из-за идеи кастомности резолва

Нет же

@fes0r еще проблема: сервисы зависящие от, например, request. Т.е. per-request сервисы

@fes0r еще проблема: сервисы зависящие от, например, request. Т.е. per-request сервисы

это уже твой модуль должен как-то разрулить уж сам

мой-то разрулит

а те, кто от него зависит не оч

ну я к тому что посмотри например на штуки вроде knex

они дают тебе возможность юзать пул соединений с базой абсолютно прозрачно

там ж на выходе модуля конструктор, а не готовый сервис

для такого потом DI и нужен)

ну либо я не понял

ну тип того)

ты можешь сделать промежуточный модуль который будет предоставлять тебе все готовенькое

но хз

могу, если он нужен один

мне тоже не шибко нравятся модули, они хороши когда нет стэйта или контекста

per-request очевидно могут жить параллельно несколько

угу

DI 1 : Modules 0

с другой стороны модули дают тебе возможность юзаать разные версии одних и тех же зависимостей в рамках разных модулей

хотя не факт конечно что это именно заслуга модулей

ммм

а можно пример?)

не, мне это ненадо было никогда но часто слышу нытье что "а вот у нас нельзя так а хочется"

ну ты про неплоскую структуру npm-modules?

тип того

а вообще если сравнивать чисто esm и java пакеты

у тебя по сути наличие export лишь говорит о том что ты что-то публичное выплевываешь, могут быть и приватные штуки

ну жава пакеты ж не суют наружу готовые сервисы, если только это не SmthUtils )

а import это просто import

ну жава пакеты ж не суют наружу готовые сервисы, если только это не SmthUtils )

посмотри на kotlin, там ты можешь сделать пакет чисто с функциями

и выходит тоже самое

у тебя есть пакеты предоставляющие классы и есть классы + функции, есть просто функции

а ты уже можешь сделать IoC контейнер если захочешь

что-то вроде... import {doSomeMath} from 'cleverModule' import {Connection} from 'db'; export class SomeStuff { constructor(private connection: Connection); }

и где-то сверху будет что-то типа

import {Connection, PgConnection} from 'db'; bind(Connection).to(PgConnection);

хз

интроспекции как бы нет потому всеравно все грустно)

тоесть есть но нет информации о типах и потому тебе надо лепить уже на чем-то совсем сверху что с может сгенерить биндинги и фабрики в compile-time

здоров, сишарперы есть?

ERROR: S client not available

а тебе зачем?)

конечно же в корыстных целях)

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

ок, понял

тоесть есть но нет информации о типах и потому тебе надо лепить уже на чем-то совсем сверху что с может сгенерить биндинги и фабрики в compile-time

ну да

фейсбук в реакте кстати делает что-то вроде let service1; export function injectService(s) { service1 = s; } export function doSmth() { service1.doSmth(); }

проблема в том, что нереально понять, как сбилдить модуль

ну и это еще дико неудобно, если делаешь руками

https://medium.com/@agent47darksoul/lets-talk-about-object-oriented-programming-d9f1602ebaa7#.gq0ojvy2l

оч крутая статья

да, неплохая

ну там еще оригинал стоит почитать

он больно упорот

помню летом даже перевод на хабрах всяких собрал "интересные мнения" в комментах...

оригинал, в смысле статью, на которую написан этот ответ

@fes0r а LIFT для структуры проекта нигде кроме ангуляра не используется?

@fes0r а LIFT для структуры проекта нигде кроме ангуляра не используется?

подозреваю что просто по другому называют эти принципы

мне просто понравилось и я для симфони накидал

вот мне было бы интересно поглядеть как вне жс это живет

https://gist.github.com/fesor/76d39b19b18f7103a7c058301dc6a8fe

ну да, я про нее

ну как, это просто проект с нормальным разделением на модули

)

модули, слои...

coupling coheasion

что бы удобно было

у меня пока есть пара моментов которые делают это неудобным (мэппинги доктрины)

нигде не надо было свои операторы в doctrine закинуть?