glinq: LINQ для Go с ленивыми вычислениями

[Dhwtj]

Наверное, хотя бы дженерики

func Process[T constraints.Integer | constraints.Float](numbers []T) []T {
    return glinq.From(numbers).
        Where(func(x T) bool { return x > 0 }).
        // Select(func(x T) T { return x * 2 }) — тут проблема

[Dhwtj]

C#

IEnumerable<T> Process<T>(IEnumerable<T> numbers) where T : INumber<T> =>
    numbers
        .Where(x => x > T.Zero)
        .Select(x => x * (T.One + T.One))
        .Where(x => x < T.CreateChecked(100))
        .Take(10);

Go

func Process[T constraints.Integer | constraints.Float](numbers []T) []T {
    var zero T          // автоматически 0
    two := T(2)         // так кастуется в Go
    hundred := T(100)
    return glinq.From(numbers).
        Where(func(x T) bool { return x > zero }).
        Select(func(x T) T { return x * two }).
        Where(func(x T) bool { return x < hundred }).
        Take(10).
        ToSlice()
}

Непривычно, но ок.

[Melpomenna]

Спасибо за обзор, очень интересная возможность для языка.

[ROuser]

Несколько вызовов Where() объединяются логически. Итерация начинается только при вызове ToSlice() и останавливается после Take(2) – Charlie даже не будет проверен.

По идее кода, разве не должен взять сначала два элемента, что удовлетворяют первому условию (Алина и Чарли), а потом проверить активность (или пусть даже полностью пропустить Алину и встать на Чарли)? Ясное дело, что итерации начнутся при вызове ToSlice, но сам Чарли явно проходит по первому Where и Take(2), что делает его участником процесса. Если я как-то неправильно понял суть кода, буду рад мудрым пояснениям.

[Larymar]

Спасибо, что отметили. Кажется новая формулировка лучше отображает реальность происходящего.

[Kayzel]

Осталось сделать апи для вытягивания данных из бд и уже можно будет полноценно на язык переходить наверное...

[Larymar]

Хах, забавное. Гошники правда вас камнями закидают. Мне бы хотелось, но доступного дешевого Expressionв go не завезли. А рефлексия похоронит всю идею моего продукта.