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

ну интерфейсов же не будет) Будут сигнатуры функций

Я не про interface.

Я посмотрел доклад про Dependency rejection от Марка Симанна или как его там. На его примере выглядит вполне неплохо, хотя пример очень скромен в объеме

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

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

Я посмотрел доклад про Dependency rejection от Марка Симанна или как его там. На его примере выглядит вполне неплохо, хотя пример очень скромен в объеме

Но у него же про другое. У тебя просто DI на частичном применении, а у него про разделение чистого кода без зависимостей и всего остального.

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

Верно. Но тут есть бонус — у тебя работает навигация по коду, и все заисимости отслеживаются в компайл тайме.

Верно. Но тут есть бонус — у тебя работает навигация по коду, и все заисимости отслеживаются в компайл тайме.

Дак ты можешь того же эффекта добиться с помощью DI через инжект руками в конструкторе объекта.

:)

Но у него же про другое. У тебя просто DI на частичном применении, а у него про разделение чистого кода без зависимостей и всего остального.

У него и про то, и про другое. Но сквозь все это проходит Dependency rejection. Про разделение чистого от нечистого он уже во второй части начал, когда не смог на хаскель портировать

У него и про то, и про другое. Но сквозь все это проходит Dependency rejection. Про разделение чистого от нечистого он уже во второй части начал, когда не смог на хаскель портировать

Нет.

Дак ты можешь того же эффекта добиться с помощью DI через инжект руками в конструкторе объекта.

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

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

Не наследуй. :)

я-то и не наследую. Оно блять до меня уже так унаследовано, что мне только щепотку базилика добавить остается

К сожалению, наследование такой общепринятый паттерн в сишарпе

И используют его странно

Нет.

У него суть в том, что DI -- это не функционально (даже через час исное применение). Он показывает это на примере Haskell, а потом переходит к Deoendency Rejection.

я-то и не наследую. Оно блять до меня уже так унаследовано, что мне только щепотку базилика добавить остается

А о чем речь-то ведем? Сначала было про DI и F#, теперь C#. :)

Ну, короче, детали реализации не очень интересные. Есть разные способы управления зависимостями, и, кажется, просто протаскивать их через аргументы функции -- один из самых неудобных методов.

Глобально о том, что ООП не подходит для сегодняшних задач. Локально об управлении зависимостями в сишарпе и фшарпе

Глобально о том, что ООП не подходит для сегодняшних задач. Локально об управлении зависимостями в сишарпе и фшарпе

Это чушь же.

я возможно не однозначно выразился

Ну я бы сказал, что подходы, применимые в сишарп,не слишком применимы в фшарп

Я не к тому, что ООП устарело и его пора на свалку и ФП ололо будущее. Я к тому, что организовывать логику поведения через объекты неправильно, и что объекты нужны для другого

В с# берут одну сущность и начинают на неё накручивать всякого

Я не к тому, что ООП устарело и его пора на свалку и ФП ололо будущее. Я к тому, что организовывать логику поведения через объекты неправильно, и что объекты нужны для другого

Почему через модули ML, например, правильно, а через объекты -- нет?

Отсюда di и прочее

Почему через модули ML, например, правильно, а через объекты -- нет?

Ну я выше объяснял, почему. Но это, конечно, все еще только мое мнение

Ну я выше объяснял, почему. Но это, конечно, все еще только мое мнение

Не, я не про куцые F# модули говорю.

А про настоящие first-class модули в ML.

Пушто логически сервис — это блок функций. А технически — объект. Из-за такого несоответствия идеи и реализации всегда возникают проблемы

Технически это тоже функция

С набором стейтов

А про настоящие first-class модули в ML.

Там нет псевдо-состояния. Там чистые функции используют чистые функции в идеале

Технически это тоже функция

как это? public class MyService же, с конструктором, временем жизни и всем остальным

Я на самом деле разобраться хочу, а не просто поспорить ради спора

как это? public class MyService же, с конструктором, временем жизни и всем остальным

Ну смотри

Класс это способ группировки в общем-то

Т.е. я группирую набор функций по определенному признаку

А давайте в качестве бреда предположим что класс это стейт + набор функций его мутирующих (+ сайд эффекты). И чтобы каждый раз это не рассказывать, можно сказать слово класс!

Я вот чую, что можно как-то нормально управлять зависимостями без этих безумных DI фреймворков. У меня уже есть хороший пример, во что использование DI может превратиться в C# на сложном проекте, но нет нормального примера на F#

Нет никаких безумных DI-фреймворков. Есть DI-контейнеры и есть попытки скрестить ужа с ежом, втащив DI в тот или иной фреймворк

ничего плохого в классах я кстати не вижу. Пользуюсь ими. Гораздо реже чем когда писал на C#, но пользуюсь

Но потом мне начинает хотеться добавить стейт и получается то, что ваше Ayrat написал

С функциями проще, но кое-что на классах получается лучше

Там нет псевдо-состояния. Там чистые функции используют чистые функции в идеале

Нет. Суть в параметризации. И модули ML, и объекты ты можешь параметризовать. Это делает их пригодными для задач DI.

А давайте в качестве бреда предположим что класс это стейт + набор функций его мутирующих (+ сайд эффекты). И чтобы каждый раз это не рассказывать, можно сказать слово класс!

ну я это и имел ввиду

Модули в F# не параметризуются.

Модули в F# не параметризуются.

К сожалению

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

Не надо использовать наследование

Короче, довольно странно, что все хейтят ООП, когда в F# — это основной способ делать нормальные абстракции.

Как раз за счет того, что объекты параметризуются.

Можно даже мутабельный стейт и наследование не делать.

Это как всегда - хейтят почему-то инструмент, а не кривизну собственных рук

+

я не хейтил ООП ни разу сейчас, есличо

я не хейтил ООП ни разу сейчас, есличо

Зато про DI написал много прочувствованных слов :)

Короче, довольно странно, что все хейтят ООП, когда в F# — это основной способ делать нормальные абстракции.

Я за себя скажу (хоть ты и не обращался ко мне лично) что я хейчу бездумное ООП. Равно как я хейчу бездумное ФП. Мне лично кажется вырвиглазным дот-фри нотация в её экстремуме. Я лично именно потому и полюбил F# потому что он позволяет говнокодить при необходимости. А работа обычно без говнокода не обходится Вместо того чтобы думать какую бы абстракцию навернуть в хаскеле чтобы на консольку распечатать (я утрирую, но всё же), я просто печатаю в консольку

Да. Я не исключаю, что DI активно абьюзится на моем проекте, но что бы там кто ни говорил — DI фреймворки это сложная штука, в первую очередь из-за богатства функционала. И у меня есть подозрение, что они стали такими сложными, пушто люди с помощью объектов решают то, что разумнее решать с помощью функций/параметризуемых модулей и тд

Да. Я не исключаю, что DI активно абьюзится на моем проекте, но что бы там кто ни говорил — DI фреймворки это сложная штука, в первую очередь из-за богатства функционала. И у меня есть подозрение, что они стали такими сложными, пушто люди с помощью объектов решают то, что разумнее решать с помощью функций/параметризуемых модулей и тд

Ну, и модули ML сложные, и монады, и имплиситы. :(

Это дело привычки, наверное?

И правильного использования.

вот я и хочу разобраться

Да. Я не исключаю, что DI активно абьюзится на моем проекте, но что бы там кто ни говорил — DI фреймворки это сложная штука, в первую очередь из-за богатства функционала. И у меня есть подозрение, что они стали такими сложными, пушто люди с помощью объектов решают то, что разумнее решать с помощью функций/параметризуемых модулей и тд

Нет, не поэтому. DI - это всего лишь выделение композиции в отдельную ответственность. В функциональщине композиция очень простая, но за счет отсутствия изменяемого состояния

прежде, чем выступать с докладом про фшарп)

А давайте в качестве бреда предположим что класс это стейт + набор функций его мутирующих (+ сайд эффекты). И чтобы каждый раз это не рассказывать, можно сказать слово класс!

если мы находимся в терминологических понятиях современного ООП имени Гради Буча и ко, то в этом определении надо поменять: 1. слово класс заменить на объект и тогда: "Объект имеет состояние, обладает некоторым хорошо определенным поведением и уникальной идентичностью." 2. А класс соответсвенно это: " ... структура и поведение схожих объектов определяет общий для них класс; термины "экземпляр класса" и "объект" взаимозаменяемы." Так говорит учебник и тот кто его написал :) и это можно принять даже не в качестве бреда

Понеслось говно по трубам...

и если опираться на эти определения то довольно заметная часть кода современного энтерпрайза под определение объекта не подходит

Да. Я не исключаю, что DI активно абьюзится на моем проекте, но что бы там кто ни говорил — DI фреймворки это сложная штука, в первую очередь из-за богатства функционала. И у меня есть подозрение, что они стали такими сложными, пушто люди с помощью объектов решают то, что разумнее решать с помощью функций/параметризуемых модулей и тд

DI-контейнер не является фреймворком, так как не навязывает определенную композицию. DI можно вообще без контейнера сделать

Понеслось говно по трубам...

да. Нам надо бота, который бы показывал сколько дней не холиварили за ООП/ФП. Как таблички на производстве - "дней без травм - 5"

@Dolfik идея для следующего бота!!

да. Нам надо бота, который бы показывал сколько дней не холиварили за ООП/ФП. Как таблички на производстве - "дней без травм - 5"

Хорошее получилось обсуждение.

Спасибо.

@fvnever я тут упоролся

И написал через DynamicMethod и ILGenerator

Похоже теперь тормозит вызов DynamicMethod :D

Похоже теперь тормозит вызов DynamicMethod :D

а ты профилировал или на глазок?

в студии есть профилятор встроенный хороший

в ентерпрайзной

Expression похоже кидает всё в кучу

а ты профилировал или на глазок?

BenchmarkDotNet