Ох, немного неудобно так код обсуждать, в отрыве от него самого.
Но давайте попробую общё — во-первых я не могу себе позволить упрощать код, выкидывая сообщение об ошибках. А так как у нас много ленивых вычислений — верить нельзя никому.
Например — нельзя упросить `proxyUpcomingExecute`, потому что в момент его бинда к `doRequireCall` вполне возможно что `grantedItem.layer` просто отсутствует.
И так много где.
И это мы еще не вспоминаем об асинхронной инициализации сервисов.
Не совсем понимаю вопрос.
Если он в том «почему не все со всеми» — так это и не нужно и неудобно будет, здесь четкое понимание зависимостей прямо в конфигурации видно.
Если «динамическое разрешение доступа» — то по факту-то оно как раз статическое, при сборке всех зависимостей и разрешается.
Надо же, примерно в это время я и писал свой Antinite, а коллеги с хабра говорят «нечего выкладывать такое в интернеты, забирай обратно».
Ведь перспективная тема же?
Ваша статья очень полезна, помогла разобраться в понятиях.
Получилось красиво, не спорю.
Но у Вас сервис-потребитель ограничивает себя сам, а у меня сервис-поставщик и домен, в рамках которого он (поставщик) заявлен, контролирует доступность ресурса. Т.е. никто не берет чужого не потому что все честные, а потому что замок висит. В этом вся разница.
так? Если не брать совсем экстремальные варианты то вроде бы так. А значит при необходимости сделать тест нашего Foo нам надо на минуточку — найти что за объекты пробрасываются в конструктор (а если это довольно далеко от корня — могут быть нюансы), далее — найти методы этих зависимостей, которые используются (по всему коду), далее — сделать на них моки.
Или, используя велосипед — просто посмотреть в перечисление require и дать именно те методы, которые там перечислены. Все! Больше никаких зависимостей у класса нет и быть не может.
Статически объявленная гранулярность зависимостей на уровне методов.
Нет, не нужно? Точно?
Если у вас большой размер кода и нужно грамотно разделять зоны ответственностей модулей, то самое время внедрить Typescript, а не устраивать валидацию в рантайме.
Вероятно я плохо себе представляю возможности Typescript. Каким образом в нем можно разделить видимость методов, кроме как написав кучу оберток интерфейсов?
Про Proxy: во-первых, это уже часть стандарта языка, поддерживается в stable версии Node. Во-вторых, несмотря на использование Proxy, код остаётся типизированным и предсказуемым. В нем всегда можно проследить где метод декларируется и где вызывается. А в вашем подходе найти концы не представляется возможным
И что нам дает типизированность кода в вопросе доступа к методам? И видимо у меня не получилось донести идеи. Первое — концы конечно же можно найти — система в любой момент может отдать граф зависимостей. Приспособить его к тому же Atom — дело техники. Далее — приведенная Вами библиотека — классический вариант DI, разве что с TS интерфейсами, которые существуют только до момента транспилинга. И сам автор указывает на то, что извлечь из контейнера объект следует в самом верху дерева, после чего приходится носиться с этим объектом как с писаной торбой и прокидывать его дальше вглубь. Или прокинуть контейнер и получить -500 к карме. В этом отношении даже древнючий intravenous и то лучше, правда с ним мы так же в итоге не понимаем что откуда берется и что куда девается.
Интерфейсы, контракты — что-то такое слышали, но в JS, уж если у нас как-то получен объект — то ВСЕ его методы доступны. Все варианты сделать методы как бы приватными — черная магия чистой воды.
А как ограничиваеся использование в вашем решении?
Пример маловат, из него не все очевидно, мой просчет.
Все методы, объявленные в `export` конечно же будут доступны компонентам, которые имеют на это права. Но! Обычно объект имеет и приватные методы, которые используются для вынесения кода в аккуратные логичные сущности. И как мы помним, приватны они только на уровне договоренности (см первый абзац ответа). В случае использования Antinite экспортируется ТОЛЬКО то, что описано в экспорте. К приватным методам (не объявленным в экспорте) доступа нет. Вообще нет. Совсем. Никак.
Ровно как у компонентов с правами на методы уровня «чтение» не будет доступа к методам других уровней. Совсем.
И да, библиотека патчит исходные объекты. Потому что она ими владеет по праву использования. Как по мне — грех тянущий максимум на написание хорошего комментария ошибки.
Советую посмотреть на Typescript и библиотеки вроде InversifyJS.
Что именно в Typescript позволяет реализовать хотя бы DI? В Typescript есть что-то для контроля доступа к синглтонам? Аудит их использования?
InversifyJS — забавная вещица, но вот вы мне патчить исходные объекты запрещаете, а там во весь рост Proxy используются, которы мало того что пока в драфте, так еще и, положа руку на сердце, делают тоже самое, по сути.
Ухх! Какая дикая дичь! Это — в походы! Собрать умника, который это написал, в ПВД2Д со всей этой ерундой, для прочищения чакр.
Если кому то действительно внезапно стала интересна тема походов и он хотел бы узнать по снаряге — есть мультибренд, человек-параход и просто отличный малый Денис Доропей. Есть вдумчивый зануда-профессионал Комбриг. Есть просветленный Леопард Фил, экстремал, но пишет отлично. Есть общие советы от всяких инет магазинов, типа Спорт-Марафона. Много всего есть и по снаряге и по подготовке походов в сети, но вот эта рекламная фигня — это треш, угар и содомия!
Одна из немногих приличных вещей тут- палатка, но ультралайт силиконка не для начинающих! А все остальное а большей своей массе — блестящее барахло. Отложите денежку для нормального снаряжения. Или сходите в платный ПВД, за 2-3 штуки вам выдадут и спальное место и еды, идти можно хоть с городским рюкзаком.
Вот простите, не содержался прям! Сбор рюкзака, тоже мне!
Ох. Вы только не обижайтесь, идея здравая, но её качество вам бы подкачать.
var workerCount = require('os').cpus().length;
не делайте так, процы с гипертрейдингом (или как там называется эта маркетинговая шляпа) наивно отдают х2 ядер, что по факто вранье и толком не работает. Вынесите в конфиг.
Статус 999 — детский сад. Есть rfc на статусы ответов, возьмите подходящий код.
Забудьте про синхронные вызовы. ИМХО их использование нельзя оправдать ничем. Ну разве что эмм. невысоким уровнем разработчика. Очень невысоким.
Забудьте про global. Или реквайрте явно, или передавайте параметром. Глобали вообще нет оправданий, даже если это написал Ризинг. Но он так не сделает.
Именование функций местами сбивает с толку. Не пишут ok, пишут isOk, ибо булен-флаг.
И последнее (на что у меня хватило сил) — реквайр ноды устроен хитро и конечно же кеширует последующие require, но идея делать его на каждый запрос вызывает оторопь.
Вот таки да, у нас реклама висит — «отдохните в отпуске в кредит!»
ИМХО если денег нет — какой нафик отпуск?
На деньги, которых у них нет люди покупают вещи которые им не нужны :)
Кто-то решил по тягаться с китайцами?
Ну, подождем реальной железки, посмотрим как играть будет, хотя сомнительно что переплюнет 200-250 баксовые модели.
И да, аудиофилы — не более больные чем геймеры или горнолыжники, просто у всех свой приход :)
Ох, как-то привык в JS к тому что создать объект ничего не стоит, так что совсем красиво не сделать, в яве хешмапы жуть какая-то (как-то раньше пристально не смотрел на нее).
А вообще конечно по нормальному нужно вести от общего к частному
vw.setScrollBarVerticalEnabled(false);
Что все равно ужасно, но хоть логичнее по структуре.
Меня больше всего во всем этом цирке 2 вещи забавят:
1. Никто не боится демонстрировать в магазинах фрагменты трупов расчлененных млекопитающих, отличающихся от людей на 2-3% по ДНК. Никого не беспокоят выставленные свиные головы и прочее. А видите ли человеческий трупик — это прям ужас-ужас!
2. Все больше вводится всякого маразма «оградить и не пущать», но строго до 18! С первым звонком взрослой жизни опекаемое доселе чадо получает обязанность взять в руки огнестрел и уже получить навык «зачистки». Так вот, без лишних ласк.
Нужно не от информации «вредной» защищать, а учить критически мыслить и верно ещё оценивать — но они же на самом деле не идиоты — рыть самим себе могилки :-)
В чистом итоге — сраное ханжество, морализм, попил бюджетов и попрание прав и свобод.
тут в трех местах поперхнутся можно.
И самое главное — непонятно зачем извращаться с поддержкой очередей если есть async? Ну допилить кое-чего по мелочи, но там все красивое уже есть.
Но давайте попробую общё — во-первых я не могу себе позволить упрощать код, выкидывая сообщение об ошибках. А так как у нас много ленивых вычислений — верить нельзя никому.
Например — нельзя упросить `proxyUpcomingExecute`, потому что в момент его бинда к `doRequireCall` вполне возможно что `grantedItem.layer` просто отсутствует.
И так много где.
И это мы еще не вспоминаем об асинхронной инициализации сервисов.
Если он в том «почему не все со всеми» — так это и не нужно и неудобно будет, здесь четкое понимание зависимостей прямо в конфигурации видно.
Если «динамическое разрешение доступа» — то по факту-то оно как раз статическое, при сборке всех зависимостей и разрешается.
Ведь перспективная тема же?
Ваша статья очень полезна, помогла разобраться в понятиях.
Ну и да, что-то по вашему получается «не читал, но осуждаю». Почитайте, бывает интересно.
Но у Вас сервис-потребитель ограничивает себя сам, а у меня сервис-поставщик и домен, в рамках которого он (поставщик) заявлен, контролирует доступность ресурса. Т.е. никто не берет чужого не потому что все честные, а потому что замок висит. В этом вся разница.
Давайте зайдем все же рассмотрим вариант интеграции с DI.
В любом варианте мы в итоге имеем что-то типа
так? Если не брать совсем экстремальные варианты то вроде бы так. А значит при необходимости сделать тест нашего Foo нам надо на минуточку — найти что за объекты пробрасываются в конструктор (а если это довольно далеко от корня — могут быть нюансы), далее — найти методы этих зависимостей, которые используются (по всему коду), далее — сделать на них моки.
Или, используя велосипед — просто посмотреть в перечисление require и дать именно те методы, которые там перечислены. Все! Больше никаких зависимостей у класса нет и быть не может.
Статически объявленная гранулярность зависимостей на уровне методов.
Нет, не нужно? Точно?
Вероятно я плохо себе представляю возможности Typescript. Каким образом в нем можно разделить видимость методов, кроме как написав кучу оберток интерфейсов?
И что нам дает типизированность кода в вопросе доступа к методам? И видимо у меня не получилось донести идеи. Первое — концы конечно же можно найти — система в любой момент может отдать граф зависимостей. Приспособить его к тому же Atom — дело техники. Далее — приведенная Вами библиотека — классический вариант DI, разве что с TS интерфейсами, которые существуют только до момента транспилинга. И сам автор указывает на то, что извлечь из контейнера объект следует в самом верху дерева, после чего приходится носиться с этим объектом как с писаной торбой и прокидывать его дальше вглубь. Или прокинуть контейнер и получить -500 к карме. В этом отношении даже древнючий intravenous и то лучше, правда с ним мы так же в итоге не понимаем что откуда берется и что куда девается.
Пример маловат, из него не все очевидно, мой просчет.
Все методы, объявленные в `export` конечно же будут доступны компонентам, которые имеют на это права. Но! Обычно объект имеет и приватные методы, которые используются для вынесения кода в аккуратные логичные сущности. И как мы помним, приватны они только на уровне договоренности (см первый абзац ответа). В случае использования Antinite экспортируется ТОЛЬКО то, что описано в экспорте. К приватным методам (не объявленным в экспорте) доступа нет. Вообще нет. Совсем. Никак.
Ровно как у компонентов с правами на методы уровня «чтение» не будет доступа к методам других уровней. Совсем.
И да, библиотека патчит исходные объекты. Потому что она ими владеет по праву использования. Как по мне — грех тянущий максимум на написание хорошего комментария ошибки.
Что именно в Typescript позволяет реализовать хотя бы DI? В Typescript есть что-то для контроля доступа к синглтонам? Аудит их использования?
InversifyJS — забавная вещица, но вот вы мне патчить исходные объекты запрещаете, а там во весь рост Proxy используются, которы мало того что пока в драфте, так еще и, положа руку на сердце, делают тоже самое, по сути.
Если кому то действительно внезапно стала интересна тема походов и он хотел бы узнать по снаряге — есть мультибренд, человек-параход и просто отличный малый Денис Доропей. Есть вдумчивый зануда-профессионал Комбриг. Есть просветленный Леопард Фил, экстремал, но пишет отлично. Есть общие советы от всяких инет магазинов, типа Спорт-Марафона. Много всего есть и по снаряге и по подготовке походов в сети, но вот эта рекламная фигня — это треш, угар и содомия!
Одна из немногих приличных вещей тут- палатка, но ультралайт силиконка не для начинающих! А все остальное а большей своей массе — блестящее барахло. Отложите денежку для нормального снаряжения. Или сходите в платный ПВД, за 2-3 штуки вам выдадут и спальное место и еды, идти можно хоть с городским рюкзаком.
Вот простите, не содержался прям! Сбор рюкзака, тоже мне!
не делайте так, процы с гипертрейдингом (или как там называется эта маркетинговая шляпа) наивно отдают х2 ядер, что по факто вранье и толком не работает. Вынесите в конфиг.
Статус 999 — детский сад. Есть rfc на статусы ответов, возьмите подходящий код.
Забудьте про синхронные вызовы. ИМХО их использование нельзя оправдать ничем. Ну разве что эмм. невысоким уровнем разработчика. Очень невысоким.
Забудьте про global. Или реквайрте явно, или передавайте параметром. Глобали вообще нет оправданий, даже если это написал Ризинг. Но он так не сделает.
Именование функций местами сбивает с толку. Не пишут ok, пишут isOk, ибо булен-флаг.
И последнее (на что у меня хватило сил) — реквайр ноды устроен хитро и конечно же кеширует последующие require, но идея делать его на каждый запрос вызывает оторопь.
В общем у вас есть место для улучшений.
ИМХО если денег нет — какой нафик отпуск?
На деньги, которых у них нет люди покупают вещи которые им не нужны :)
Ну, подождем реальной железки, посмотрим как играть будет, хотя сомнительно что переплюнет 200-250 баксовые модели.
И да, аудиофилы — не более больные чем геймеры или горнолыжники, просто у всех свой приход :)
А вообще конечно по нормальному нужно вести от общего к частному
Что все равно ужасно, но хоть логичнее по структуре.
Разработчика нужно
п… дить кирзачамиотрывать рукидать в репузаставить самого этим пользоваться.Этож просто какая-то жесть.
А по итогу-то что получается — только Java, только хардкор? Как не посмотрю — все кривенько :(
1. Никто не боится демонстрировать в магазинах фрагменты трупов расчлененных млекопитающих, отличающихся от людей на 2-3% по ДНК. Никого не беспокоят выставленные свиные головы и прочее. А видите ли человеческий трупик — это прям ужас-ужас!
2. Все больше вводится всякого маразма «оградить и не пущать», но строго до 18! С первым звонком взрослой жизни опекаемое доселе чадо получает обязанность взять в руки огнестрел и уже получить навык «зачистки». Так вот, без лишних ласк.
Нужно не от информации «вредной» защищать, а учить критически мыслить и верно ещё оценивать — но они же на самом деле не идиоты — рыть самим себе могилки :-)
В чистом итоге — сраное ханжество, морализм, попил бюджетов и попрание прав и свобод.
тут в трех местах поперхнутся можно.
И самое главное — непонятно зачем извращаться с поддержкой очередей если есть async? Ну допилить кое-чего по мелочи, но там все красивое уже есть.