Я не про вернуть, просто файлик всё еще на гитхабе (хоть бы и по той же ссылке выше). Кстати ссылка на сам коммит, кажется, будет работать даже если коммит удалить из истории :)
Вообще подумалось, что step() и step(result) тоже должны иметь право возвращать Reduced, но у Рича это явно не так для step(), и не понятно для step(result).
Наверно нужно уже в исходники кложуры лезть чтобы разобраться.
В первом примере всё правильно. Если стоит take(3), то должно вернуться 3 элемента не больше. Представьте как это было бы если бы мы постаринке делали с временными коллекциями.
По поводу второго есть в посте:
Еще придется добавлять проверку Reduced.isReduced(result) в трансдьюсеры, которые несколько раз вызывают step (прим. flatten).
Да, step() без параметров вызывается только 1 раз — вначале. Он вызывается во внешенм коде, сами трансдьюсеры не должны его вызывать (только если их самих вызвали без параметров).
Тоже самое и для step() с одним параметром, его можно, и нужно, вызывать только если ваш step вызвали с одним параметром.
Резервировать undefined всё таки неправильно, посмотрите мой пример с потоком habrahabr.ru/post/237733/#comment_7998887, я там использую null (потому что результат никуда сохранять не нужно), но кто-то может захотеть использовать undefined, и я считаю он имеет полное право использовать undefined.
Также, мне сейчас не хочется думать какие еще могут возникнуть проблемы (кроме того, что обрабатываем на один элемент больше), но у меня есть сильное предчувствие, что это даст нам еще какие-то ограничения.
Думаю идеальным было бы сделать такой редьюсд `{__transducersReduced__: true, wrapped: result}`, тогда мы наложим минимум ограничений, и избавимся от привязки к конкретной библиотеке.
Я бы не начинал всё направо и налево называть трансдьюсерами :) Всё-таки у них есть пока-что четкая спецификация. Просто именно так мы отдаляемся от светлого будущего, в котором многие библиотеки будут поддерживать трансдьюсеры как протокол и смогут друг с другом тесно взаимодействовать через этот протокол.
Мы с вами в одинаковом положении потому что я с генераторами очень мало знаком пока :)
Подозреваю что многое из этого всего можно сделать на генераторах, да.
В этом что-то есть :)
Нужно репозиторий удалять.
Дописал дополнение к статье. Т.е. теперь можно делать take+append и всё будет работать!
Наверно нужно уже в исходники кложуры лезть чтобы разобраться.
Но в FRP ничего не потеряется, там Reduced всплывет, и мы узнаем что нужно закрывать поток.
По поводу второго есть в посте:
Тоже самое и для step() с одним параметром, его можно, и нужно, вызывать только если ваш step вызвали с одним параметром.
Резервировать undefined всё таки неправильно, посмотрите мой пример с потоком habrahabr.ru/post/237733/#comment_7998887, я там использую null (потому что результат никуда сохранять не нужно), но кто-то может захотеть использовать undefined, и я считаю он имеет полное право использовать undefined.
Также, мне сейчас не хочется думать какие еще могут возникнуть проблемы (кроме того, что обрабатываем на один элемент больше), но у меня есть сильное предчувствие, что это даст нам еще какие-то ограничения.
Думаю идеальным было бы сделать такой редьюсд `{__transducersReduced__: true, wrapped: result}`, тогда мы наложим минимум ограничений, и избавимся от привязки к конкретной библиотеке.
Подозреваю что многое из этого всего можно сделать на генераторах, да.
И может где-то что-то еще не сойдется, сейчас не приходит в голову.