Для конкретного примера, да. Но прикинем что все аргументы имеют разный тип и нам нужно сделать что-то сложное с ними, пожалуй тут уже без зипов будет совсем не красиво
Да уж, а все почему? Потому что людей учат писать изначально на pascal, C++, Java и т.д. Они однопарадигмовые и это закрывает умы для других подходов. Вот если бы начинали учить людей с Python или Ruby. То может и разнообразия было бы больше :)
Боюсь, что без велосипедостроения не получится, так как создатели не предоставили нам zipAll.
Можно написать implicit class, в котором написать zipAll принимающий от 2 до 21 Future в качестве аргументов (так как последний Tuple22). Но мне кажется это уже излишество. Способ с кучей скобочек ни чем не плох (вспомним lisp) :)
Текст рассчитан на людей, которые уже имеют некоторое представление о Scala и о монадах, и жизнь их натолкнула на scala.concurent.Future.
Вам же предлагаю, а потом еще разок прочитать эту статейку, думаю все встанет на свои места :)
Многим кажется, что они поняли монады после знакомства Maybe. На самом деле всё немножно сложнее, ведь каждую монаду приходится осознавать заново.
естественно каждая монада личность :)
Код повысит входную планку для читателей. Для просвещённых он будет читабельнее, для большинства же — врядли.
Согласен, но начать читать не так уж и сложно.
Maybe/Optional не спасают от ошибок, они лишь указывают о возможности ошибки на уровне системы типов. Без статической проверки типа от них гораздо меньше прока
Прока может быть и меньше, но все же если придерживаться того, что null — это значение, а не его отсутствие, и пользовать где нужно Maybe. Должны полностью убрать возможность пропустить какой нибудь null там где это не ожидается
Да конечно особо они не нужны (да что уж там, я бы назвал это баловством), особенно в нетепизированных то языках. Но если пользоваться с умом, то код станет в разы чище и читабельнее.
И да конечно же, да прибудет функциональщина, за лямбду!
P.S. Тут скорее идет не приправление функциональщины ООП, а наоборот. Сколько раз я проклинал NPE после использования скалы с Option'ами…
Спасибо, поправил.
Ну каждому свое, меня больше устраивает подход: more think — less write, а с for — больше букав :)
Можно написать implicit class, в котором написать zipAll принимающий от 2 до 21 Future в качестве аргументов (так как последний Tuple22). Но мне кажется это уже излишество. Способ с кучей скобочек ни чем не плох (вспомним lisp) :)
Вам же предлагаю, а потом еще разок прочитать эту статейку, думаю все встанет на свои места :)
трекпад просто начать использовать, здесь же придется изрядно попотеть
естественно каждая монада личность :)
Согласен, но начать читать не так уж и сложно.
Прока может быть и меньше, но все же если придерживаться того, что null — это значение, а не его отсутствие, и пользовать где нужно Maybe. Должны полностью убрать возможность пропустить какой нибудь null там где это не ожидается
И да конечно же, да прибудет функциональщина, за лямбду!
P.S. Тут скорее идет не приправление функциональщины ООП, а наоборот. Сколько раз я проклинал NPE после использования скалы с Option'ами…