Причем inline как то с таким подходм разбирается. Но ведь в данном случае даже инлайн не нужен. Типя статически могут поддерживать ту или иную операцию. В общем я слегка оболдел, сколько надо написать бойлера, что бы добавить свою операцию, не прикрывая уже существующего определения напрочь.

Ты умеешь перегружать операторы для собственных типов?

Для собственных - да. К сожалению для FSharpFunc - не могу

Для собственных - да. К сожалению для FSharpFunc - не могу

В чем тогда вопрос? Мы не можем перегружать операторы для чужих типов, потому что у нас нет тайпклассов или их аналога.

Тебе даже PR и RFC скинули на эту тему.

let (>=>) f1 f2 = fun a -> match f1(a) with | Option t -> f2(t) | _ -> None let (>=>) f1 f2 = fun a -> match f1(1) with | Result t -> f2(t) | Error e -> Error e Почему нельзя так, ведь все для компилера уже известно на момент вызова?

let (>=>) f1 f2 = fun a -> match f1(a) with | Option t -> f2(t) | _ -> None let (>=>) f1 f2 = fun a -> match f1(1) with | Result t -> f2(t) | Error e -> Error e Почему нельзя так, ведь все для компилера уже известно на момент вызова?

Шедоуинг.

Да я по спеке понимаю. Но почему так сложно?

Ты спрашиваешь, почему не сделали перегрузку функций?

Даже недошенный CSharp может разобраться.

Даже недошенный CSharp может разобраться.

Не может.

Ну да - именоо это

Блин, ты различаешь функции и методы?

Хоть немного?

Ты понимаешь, что методы прикреплены к типам?

А функции — нет.

Даже недошенный CSharp может разобраться.

Давай, покажи код. :)

Да различаю. Да понимаю. Да еще и теорию типов нзнаю. И вижу что при выводе типов этот вопрос спокойно разрешим.

Давайте без ругани

Ivan Simongauz сможешь показать как компилятор мог бы разрешить эту задачу?

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

Это не оскорбление.

Так, что у вас тут? Оскорбляете друг друга? И меня не позвали?!

let f1 = fun a -> Ok a let f2 = fun a -> Some a

let f3 = fun a -> Ok a let f4 = fun a -> Some a f3 >=> f1 - тип ('T -> Option<'T>) -> ('T->Option<'T>) -> ? f4 >=> f2 - тип ('T -> Result<'T>) -> ('T -> Result<'T>) -> ? По сигнатуре понять какой оператор вызвать можно

перегрузка МЕТОДОВ в F# есть. перегрузки ФУНКЦИЙ в F# нет, изи

просто нет. С этим надо жить

Это отказываются принимать.

Да вот постояноо, что не задача, то с эти надо жить 😊

Слушайте, это уже не первый раз же. До этого просто было нытье про тайпклассы.

Нескончаемое.

Да вот постояноо, что не задача, то с эти надо жить 😊

компромиссы. Зато .NET есть со всеми нугетами, ажуром и VS

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

зато перегрузка функций есть

Через тайплклассы.

Так, что у вас тут? Оскорбляете друг друга? И меня не позвали?!

плохой человек

Ну как тебе сказать. Все ж хаскел - это теор язык. Для ученых. Но между прочим - офигенно продвинувшийся по сравнению с .net/ Компилер у них нативный и очень не плохой

Год назад,@gsomix, ты на меня за тайп классы так ругался, что чуть не забанил 😊

Потому что код надо писать, а не витать в облаках.

кот*

Он обиделся?

я согласен, что хаскель тянет ФП мир вперёд, вопросов нет. Но работать на нём - то ещё удовольствие. Можно, но это удел стартапов и просто случайных личностей. Бизнес едва подписывается работать под F#, хотя у него экосистема и всё такое. У хаскеля вообще ничего нет, всё руками делать надо

подышать вышел

Мне кажется, или @gsomix стал каким-то нервным после отпуска?)

Да, стал. Не знаю чо его так от вопроса о перегрузках бомбануло)

Обиделся. Если бы про код писать, я в б основной чат. А про тайп классы правда.

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

GADT

Ммм...... Депенденси тайпы

давно хочу

Meta programming

линейные типы. Чтоб как в раст, без гц в компайл тайме всё было ясно

Он обиделся?

У него нервы.

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

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

А можно совместить наверное. Я не специалист, так рядом проходил.

Хотя я, глядя на текущий тренд, вижу, чтоООП в том виде, который был все эти годы, сильно здает. Скоро без монад на работу не возьмт 😊

Там математика еще немного сложнее. И такие фокусы надо делать для двухсвязных списков...

да с этим ООП всё решиться не могут, то ли трусы снять, то ли крестик надеть Интерфейс может иметь дефолтные имплементации или нет? Множественное наследование и т.д.

они со своей теор базой определиться не могут, всё паттернами заливают

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

Паттерн - это нелохо. Это дисциплинирует На верхних уровнях приходит прозрение. Дальше - просто программирование. А код - вроде паттерны 😊

паттерны это хорошо, это дистилированный опыт. Просто в отрасли пытаются знание паттернов выдать за знание ООП. Типа знаешь что такое фабрика и SOLID - всё, это ООП

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

НЕ если еще, кто нибудь мне объяснит, чем адапер от декоратора отличается, а фабрика от конструктора.. Но кажется я не туда пошел 😊

НЕ если еще, кто нибудь мне объяснит, чем адапер от декоратора отличается, а фабрика от конструктора.. Но кажется я не туда пошел 😊

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

http://fssnip.net/7Vb?utm_source=dlvr.it&utm_medium=twitter

Это тролинг?

http://fssnip.net/7Vb?utm_source=dlvr.it&utm_medium=twitter

вот ты шутишь, а я так делал

на полном серьёзе

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

Все создающие паттерны умещаются внутри DI

я даже могу расказать зачем

я даже могу расказать зачем

Давай)

Все создающие паттерны умещаются внутри DI

я согласен на 100%

http://fssnip.net/7Vb?utm_source=dlvr.it&utm_medium=twitter

. Is this a serious snippet or not? No category theory and mocking frameworks are required, so probably not.

Лол

Давай)

у меня был кейс что акторы должны были отправлять сообщения о очистке своего стейта раз в день, чтобы не распухать. Надо было как-то потестировать что всё работает. Не ждать же мне день? Ну вот я и замокал DateTimeOffset.NowUtc через такой же примитивный интерфейс и в тестах подменял вызов на нужное время чтобы посмотреть что актор правильно себя ведёт во времени

при этом я могу рассказать два других способа

В DI напрямую не влезает - command, mediator, repository и т.д. Все что связанно с созданием реализации влезает - здесь я за

да с этим ООП всё решиться не могут, то ли трусы снять, то ли крестик надеть Интерфейс может иметь дефолтные имплементации или нет? Множественное наследование и т.д.

Мне кажется современное ооп - это структуры + интерфейсы. Наследование реализации признано вредным, множественное наследование интерфейсов - полезным. Дефолтные методы интерфейсов - сахар