Спасибо, кэп

да наболело просто

Сервис локатор, вот это вот всё

А видели (не то чтоб про F#, но про ФП) - там с конфы Curry On! видосы свежие подвезли https://www.youtube.com/channel/UC-WICcSW1k3HsScuXxDrp0w

вот вакансия, если интересно) https://www.linkedin.com/jobs/view/536849332/

Та о которой ты говорил?

Та о которой ты говорил?

Не, это компания в которую Михаил пошёл

Сервис локатор, вот это вот всё

Сервис локатор - это не di

это вообще ад в неумелых руках :(

Дай в неумелые руки стеклянный.... F#

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

не спорю, но кто то же должен быть тем героем)

Мы для этого и создали сообщество, людей приростпет и приростает. Это хорошо, значит басфактор снижается

у меня правда есть подозрение что средний уровень F#ера и C#ера разный, поэтому они могли выиграть не только за счёт языка

Это всегда так. Обычно те кто юзает f# неспроста его бзают, да уровень разный. Команду когда набирали обязательно спрашивал какие языки смотрел, и любой фп ориентированный язык был плюсиком, т.к. это показатель заинтересованности, а значит интереса к своему делу. Фп может и не понравиться, что норма, но то что есть интерес к другим способам - это очень важный показатель.

Никто не хочет перевести ? https://fsharp.org/specs/component-design-guidelines/

В с# почти все проблемы решаются с помощью di

Без тайп классов и F# DI требует:-). А то, что DI крайне сложный концепт, как то никто и не обращает внимания.

Никто не хочет перевести ? https://fsharp.org/specs/component-design-guidelines/

Issue?)

у меня правда есть подозрение что средний уровень F#ера и C#ера разный, поэтому они могли выиграть не только за счёт языка

Дык чтобы топить за C# против F# надо уже иметь не слишком высокий скилл

Без тайп классов и F# DI требует:-). А то, что DI крайне сложный концепт, как то никто и не обращает внимания.

Не понимаю, что в нем такого сложного. Паттерн простой как полено.

Не понимаю, что в нем такого сложного. Паттерн простой как полено.

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

философски он непрост.

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

Там все просто :) Передавай все зависимости только через конструктор. Разрешай их в одной точке сборки. В общем-то на этом все.

Там все просто :) Передавай все зависимости только через конструктор. Разрешай их в одной точке сборки. В общем-то на этом все.

это правильный подход. А есть же любители propery injection через атрибуты и метаданные

Фабрика сложнее, вдобавок полностью покрывается DI

я вот пока на C# писал обожал SimpleInjector, который вовсе не Simple

он вообще руки по локоть отрывал если у тебя граф зависимостей не собирался

я вот пока на C# писал обожал SimpleInjector, который вовсе не Simple

Самое лживое слово в нашей отрасли - "просто"

А ещё SimpleInjector форсил правильный DI. Контейнер становился ридонли после первого ресолва (т.е. никакой магии с автосканированием типов чтобы в динамике отресолвить), запрещалось иметь более одного публичного конструктора, запрещалось иметь несобираемые типы (форсилось через проверку в композишн руте). Для IDisposable надо было или явно говорить контейнеру на регистрации - отвали, я сам его отдиспозю, или указывать в каком скоупе этот IDisposable существует (скоупы там есть на асинк операцию, на веб запрос и т.д.) И при этом он чудовищно быстрый.

Там все просто :) Передавай все зависимости только через конструктор. Разрешай их в одной точке сборки. В общем-то на этом все.

Расскажи это андроид девам, когда надо инжектить в компоненты, которые создаёт система =)

у них там в джаве полный ад в DI, страшно смотреть

Расскажи это андроид девам, когда надо инжектить в компоненты, которые создаёт система =)

Это проблема не в DI, а в говенных фреймворках

у них там в джаве полный ад в DI, страшно смотреть

В джаве ещё более менее. В андроид ад

это они придумали xml конфигурации для контейнера! и метод инжекшны! и проперти инжекшны!! и вообще всё плохое придумали они)

В яве - ад и содом, в лучшем случае на аннотациях

А флюент-конфигурации кодом - нет

И это песец

Это проблема не в DI, а в говенных фреймворках

Так да, никто и не говорит что во фреймворках проблема. Просто из такого говна как андроид приходится воротить всякие даггеры

Но умея в DI, говнистость фреймворка можно купировать

Вспомните коллеги, что все продвинутые DI умеют разрешать generics с интсанциацией типа. Если это просто, то я уже не знаю, что сложно ?

ауч, да что же привязался к нам этот господин (или бот)

Вспомните коллеги, что все продвинутые DI умеют разрешать generics с интсанциацией типа. Если это просто, то я уже не знаю, что сложно ?

Контейнер - всего лишь инструмент. Паттерн простой. Инструмент может быть и сложным.

Паттерн - комбинация фабрики, синглтона, области видимости, метаинформации, адаптера, декоратора, перехвата типов. Совсем просто ?

Как раз всех паттернов, реализуемых в FP функциями кстати.

Ради представления о навороченном способе проетирования с испоьзованием DI можно например посмотреть на реализацию Microsoft.Extesions.Options. Вставляет солидно.

Почти функциональный код, несмотря на ООП.

Ещё можно почитать блог Марка Симана — он в последних постах натягивает ФП на ООП (Church Encoding) http://blog.ploeh.dk/

ауч, да что же привязался к нам этот господин (или бот)

@gsomix @fvnever @neftedollar

?

на свет летят что ли

А я этого автора ботов недавно на местном канале видел, думал он здешний, а оказалось мимо шёл

https://twitter.com/zaid_ajaj/status/1021568445924683776

Одмены, добавьте бота, который трёт системные сообщения телеги.

Одмены, добавьте бота, который трёт системные сообщения телеги.

Тогда бездушная машина оставит гсомека без работы

xD

Этого ли мы добиваемся?...

Ну, его на f# можно написать.

Тогда бездушная машина оставит гсомека без работы

тогда бот должен ещё говорить: привет

тогда бот должен ещё говорить: привет

Ну нельзя настолько жестоко)

тогда бот должен ещё говорить: привет

Привет пока

Ну, его на f# можно написать.

@gsomix 'а даже на f# тяжело написать

https://twitter.com/henrikfeldt/status/1021465478269632513?s=19

Как-то не быстрый chiron

fsharplu же надстройка на json.net?

Он ещё и неудобный жутко. Фп ради фп

Он ещё и неудобный жутко. Фп ради фп

а мне зашло =D

А вот что делать когда надо из гигантского полотна жсона вытащить значения 4го уровня вложенности? В хироне - страдать и лепить модели на каждый чих с кучей методов. В ньютонсофте selectTokens "abc.dfg[*].vvv.id" |> ofValues<Guid> и все!

Та же история с сериализацией. Я не хочу думать об инфраструктурном коде. Я вообще код не хочу писать, поэтому даже JsonConvert.SerializeObject для меня много, а хирон заставляет писать тонны бойлерплейта. Ради чего? Какие преимущества? Он ещё и медленнее.

Если хочется безопасной десериализации, FSharp.Json ваш выбор.

Та же история с сериализацией. Я не хочу думать об инфраструктурном коде. Я вообще код не хочу писать, поэтому даже JsonConvert.SerializeObject для меня много, а хирон заставляет писать тонны бойлерплейта. Ради чего? Какие преимущества? Он ещё и медленнее.

Ради контроля над (де)сериализацией же. Меня вполне устраивает CE Chirona, особенно когда надо добавлять правила валидации

Не совсем ясен смысл валидации при десериализации

Ради контроля над (де)сериализацией же. Меня вполне устраивает CE Chirona, особенно когда надо добавлять правила валидации

Я думаю там один контроль - фейлфаст. Если модель изменилась, эти CE не помогут

Не совсем ясен смысл валидации при десериализации

+1

Учитывая, что owasp атак на insecure deserialize в дотнете не построить

Я думаю там один контроль - фейлфаст. Если модель изменилась, эти CE не помогут

не всегда, иногда нужен фоллбэк

не всегда, иногда нужен фоллбэк

Приведи пример, выглядит как-то странно

обычно это в случае backword compatibility

Ну в трай кетч заверни тот же ньютонсофт и вот фолбек)

обычно это в случае backword compatibility

Не проще n сериализаторов?

Лучший код = ненаписанный код

Ну в трай кетч заверни тот же ньютонсофт и вот фолбек)

ну такое)

Просто выглядит как overengineered

Лучший код = ненаписанный код

так всеравно писать надо, аттрибуты Newtonsofts тоже код

Какие атрибуты?

так всеравно писать надо, аттрибуты Newtonsofts тоже код

Атрибуты? Не пользовался

Максимум climutable

На рекорд

Да и без климутабл оно уже умеет

А, у меня акка.нет требует 9 версию

если у тебя json {'abc_uname': 'luke'} а ты хочешь десериализовать это в тип { UserName: string }

это можно как-то без аттрибутов или другого кода?

Ну тут очевидно) ньютонсофт мысли читать не умеет

Но это редкость же, такие несовпаднния в именах

так в моем клиенте 99% таких json

все модели обвешены аттриубтами