Да, такой код с пересобранным мной компилятором не скомпилируется. Несколько возвращаемых выражений как у функции недопустимы для условного выражения. Поругается на запятую в nil, nil, а если это заменить на вызов функции — скажет, что используется какое-то multi-value в single-value context. Падает либо парсер, либо тайпчекер
Подобное можно позволить, но я не хотел, т.к. мне самому не очень нравятся множественные возвращаемые значения в Go, их сложно композировать и куда-то передавать. Вот, я прилагал ссылочку
Возможно, это будет связано с темой для будущей статьи, если я другую идею удачно реализую)
Была такая мысль) более общий подход на фоне условного выражения
Но здесь с учётом конструкции type-switch уже потенциально выскакивает концепция sum-типов, которые я пока не стал реализовывать в Go. Хотя, конечно, можно принудить всегда писать default-ветку и худо-бедно дело закрыто
Классная статья! Достаточно приятно все описано, с примерами, спасибо большое)
Но как будто бы в описанном в статье коде reducer просто выводит то, что наплодил shuffler. Может я что-то не так понял, но не должен ли он в finalCounts аггрегировать данные, полученные от shuffler-ов? И внешний цикл по числу mapper-ов в shuffler-е выглядит лишним...
Согласен, что в текущем состоянии языка это не сделало бы сильно хуже
Да, такой код с пересобранным мной компилятором не скомпилируется. Несколько возвращаемых выражений как у функции недопустимы для условного выражения. Поругается на запятую в
nil, nil, а если это заменить на вызов функции — скажет, что используется какое-тоmulti-valueвsingle-value context. Падает либо парсер, либо тайпчекерПодобное можно позволить, но я не хотел, т.к. мне самому не очень нравятся множественные возвращаемые значения в Go, их сложно композировать и куда-то передавать. Вот, я прилагал ссылочку
Возможно, это будет связано с темой для будущей статьи, если я другую идею удачно реализую)
Была такая мысль) более общий подход на фоне условного выражения
Но здесь с учётом конструкции type-switch уже потенциально выскакивает концепция sum-типов, которые я пока не стал реализовывать в Go. Хотя, конечно, можно принудить всегда писать default-ветку и худо-бедно дело закрыто
Классная статья! Достаточно приятно все описано, с примерами, спасибо большое)
Но как будто бы в описанном в статье коде
reducerпросто выводит то, что наплодилshuffler. Может я что-то не так понял, но не должен ли он вfinalCountsаггрегировать данные, полученные отshuffler-ов? И внешний цикл по числуmapper-ов вshuffler-е выглядит лишним...