Комментарии 6
Интересно, а чем подход как в sql.Rows не устроил, то есть сделать:
type Stream[T any] interface {
Next() bool
Scan(*T)
Err() error
}Не понимаю, для чего Option, зачем создавать себе проблемы.
Не совсем понял, какие проблемы. В стримах с моим подходом не обязательно выдаются ошибки, это раз. Два, Option это обертка над указателем, у меня, чтобы получить следующий элемент, надо просто вызвать Next, с sql.Rows надо вызвать Next, проверить значение, создать контейнер для результата, вызвать Scan. Из плюсов, что нет копирования, значение пишется в предоставленный пользователем контейнер. В моих стримах проще интерфейс и использование, но есть копирование. Я что-то упускаю?
Ну к примеру как бы выглядела реализация Map:
type mapImpl[A, B] struct {
s Stream[A]
v A
fn func(A) B
}
func (m *mapImpl[A, B]) Next() bool {
return s.Next()
}
func (m *mapImpl[A, B]) Scan(v *B) {
m.s.Scan(&m.v)
*v = m.fn(m.v)
}
// ...Увеличилась ли тут сложность? Вроде нет.
Есть простор для оптимизации? Да.
Привычно ли использование? Да, аналогично тому же sql.Rows, к примеру.
Вообще ничего против не имею вашей библиотеки. Но ошибок все-таки не хватает (того же Err()). Для продакшена такую библиотеку неудобно будет использовать, так как придётся поверх этого всего городить велосипед, чтобы ошибки поддержать (а это нормально, например когда нам пользователь что-то в сокет кладёт или ещё что).
Вообще это все сугубо мое личное мнение и я могу быть где-то не прав. Но немножко грустно, что с появлением generic-ов частенько мелькают библиотеки с как минимум сотнями звёздочек, реализующие всякие Result[T, E], Optional[T] и type Map[K, V] map[K]V. Неужели стандартные возможности языка не позволяют этого? Или у нас путь как с npm пакетами (плохое сравнение, но все же) - проще строчку в go.mod, чем одну/две в *.go
Можно пожалуйста пример реального кода где это могло бы с пользой использоваться?
Потоковая обработка на go1.18