Автор как раз на оборот не предлагает ничего менять, а говорит, что вот у вас появился новый тип Maybe<T> и остались старые функции А->B
соответственно ваш Add остается таким как бы, (int,int) -> int но его нельзя просто так использовать с новым типом, поэтому то и нужны доп телодвижения.
Скорее всего да. Например, хоть в скале и есть библиотека scalaz но насколько я понимаю большинство от нее плюются, данные концепции должны быть у истоков языка, как например в хаскеле. Если интересно, можете почитать мою старую статью habrahabr.ru/post/112464/
там используется для монад сахар от linq.
Вот что бы так не писать, я в самом последнем примере показал второе решение
discount = DiscountService.GetDiscount.Curry().Pure().Apply( userId).Apply(productId)
Которое мне кажется более прозрачным из за отсутствия if.
С динамическими тут вообще сложно сравнивать, так как там можно делать все что пожелаешь.
Но представьте если бы у вас DiscountService.GetDiscount на входе требовал что бы оба параметра были не None.
Заменил некорректное, на классическое.
DiscountService.GetDiscount(userId.Value, productId.Value)
Этот код я привел для простоты, конечно же он не корректный, так как в случае если один из них Nothing то Value == 0. Правильное решение дальше по тексту
Func<int,int,int> f = DiscountService.GetDiscount;
var discount = f.Curry().Pure().Apply(userId).Apply(productId);
Получается более прозрачная запись, так как нам вообще не приходится задумываться есть там что то в userId и productId или нет.
В заключении я как раз упомянул про List<T>. В C# наличие инструментов для других сущностный особой пользы не принесет, так как они будут не связаны, как, опять же, я написал в заключении. Не увидел смысла упоминать join, помоем достаточно bind.
А какой пример бы привели вы на C#? Мне показалось, что раз я описываю проблему и ее решение, то человек уже сам при желании может сравнить как бы он решил ее старыми способами.
Пример с GetDiscount не практический? Можно городить кучу ifов, а можно использовать абстракции. Да на C# выглядит страшно, так как он не совсем подходит под такой стиль.
Дело привычки. На F# пишут так skip 3 |> map (+1) |> filter (>3) |> length
Этот вариант наверное покажется более читабельным из-за того, что практически у всех современных языков операции над объектами идут через точку x.DoSomething()
При образовании нового типа M<A> возникают проблемы с использованием старых функций
1) A -> B
2) (A,B) -> C
Так же у нас получается новый тип функций A -> M<B> у которых есть проблемы с
3)Применением
4)Композицией между собой
5)Композицией со старыми функциями
Maybe<T>и остались старые функции А->Bсоответственно ваш Add остается таким как бы, (int,int) -> int но его нельзя просто так использовать с новым типом, поэтому то и нужны доп телодвижения.
habrahabr.ru/post/112464/
там используется для монад сахар от linq.
getDiscount <$> userId <*> productId
discount = DiscountService.GetDiscount.Curry().Pure().Apply( userId).Apply(productId)
Которое мне кажется более прозрачным из за отсутствия if.
Но представьте если бы у вас DiscountService.GetDiscount на входе требовал что бы оба параметра были не None.
Заменил некорректное, на классическое.
DiscountService.GetDiscount(userId.Value, productId.Value)Этот код я привел для простоты, конечно же он не корректный, так как в случае если один из них Nothing то Value == 0. Правильное решение дальше по тексту
Получается более прозрачная запись, так как нам вообще не приходится задумываться есть там что то в userId и productId или нет.
List<T>. В C# наличие инструментов для других сущностный особой пользы не принесет, так как они будут не связаны, как, опять же, я написал в заключении. Не увидел смысла упоминать join, помоем достаточно bind.А какой пример бы привели вы на C#? Мне показалось, что раз я описываю проблему и ее решение, то человек уже сам при желании может сравнить как бы он решил ее старыми способами.
skip 3 |> map (+1) |> filter (>3) |> lengthЭтот вариант наверное покажется более читабельным из-за того, что практически у всех современных языков операции над объектами идут через точку x.DoSomething()
складываем в каждой строке числа пока не останется одна цифра
16 = 1 + 6 = 7
17 = 8
9 = 9
Итого, справа получается число за вычетом 7
Решает проблему где то в 90% случаев.