meian / gcf Goto Github PK

• Distinct? or Unique?
  • どちらの単語がよく使われてるか確認したほうが良さそう
  • 無難にRxとかに合わせておく？
• Iterator内部でmapに過去の値を蓄積して、すでにある値だったらスキップすれば良さそう
  • ポインタ要素のIteratableだと使えなさそうなのでコメントに明記しておく

この書き方をしている場合、引数の itb にnilを渡すと emptyIterable を返すので処理が軽いが、その次に他の関数を適用したときに empty ではなくなるので空の時にも処理が軽くならない

itb := gcf.Filter[int](nil, func(v int) bool { return v > 10})  // この時点では itb は empty
itb = gcf.Filter(itb, func(v int) bool { return v%2 == 0})      // この時点では itb は filterIterable だが要素は1件も取得できない

そのため以下のように修正することで emptyIterable をチェーンできるようにする

func SomeFunc[T any](itb Iterable[T]) Iterable[T] {
    if isEmpty(itb) {
        return orEmpty(itb)
    }
    ....
}

• isEmpty
  • itb がnilか emptyIterable であればtrue
• orEmtpy
  • itb がnilなら emptyIterable、nilでなければ emptyIterable を作って返す

こうすることで empty に対する処理に対して常に empty を返せるので、空の処理の場合に負荷がかからなくなる

itb := gcf.Filter[int](nil, func(v int) bool { return v > 10})  // この時点では itb は empty
itb = gcf.Filter(itb, func(v int) bool { return v%2 == 0})      // empty に対する処理なので empty になる

#5 対応後に Renovate入れる
とりあえずはデフォルト設定で良さそう
=> あまり設定いじる必要ないのでdependabotで試してみる

Proposal.

• Change go support versions to 1.18 and 1.19
  • go.mod version is stay to 1.18.
• Update README

What benefit with the proposal?

The README description is still old, so update it.
In addition, ensure that it works with newer go version.

Others

Add any other context about the proposal here.

golang:1.18のGA出た後にdev containerのイメージを変更する。
後でrenovate入れるので、リビジョンとOSまで指定しておくこと

• SkipLast は件数を指定して末尾から除外する
• SkipLastWhile は条件を指定して末尾から一致する範囲を除外する

• サービス統合で #49 のPRが作成されたが、Go1.18が対応されていなかったので一旦クローズした
• SiderがGo1.18に対応したらPRをReopenして対応を進める
  • 一旦アプリ統合削除した気がしたので、もし作り直す場合は新規のPRで対応する

• chanからIteratableを作る
• Iteratableからchanを作る
• とりあえずはblocking実装のみにしたい
  • non blocking実装作ろうとすると、多分IteratorにMoveNextとは別にIsDoneとかつけなきゃならなそう

ある程度整理したら0.0系でライブラリのバージョンを上げてリリース作る。
0.1とかはCI作ってからで良いかな多分

Proposal.

Add linter CI.
As a candidate, https://github.com/reviewdog/action-golangci-lint

What benefit with the proposal?

Process static review on CI.

Others

Originally posted by @meian in #3 (comment)

BenchmarkFilterとBenchmarkOnLoopのallocとかが繰り返しに比例していない？
関数ネストで複雑化しているところでバグってる可能性あるので全部個別に実装してみる

READMEにdescriptionとインストール方法以外書いてないので、以下の辺りを書くこと。

• コンセプト
  • Iterator実装使ってるから中間メモリ少ないよ
  • HasNext + NextでなくてMoveNext + Currentにしたよ
    • Currentを再利用できるようにしたかった
    • 基本の使い方は for it.MoveNext() { v := it.Current() } になるのでどちらも同じといえば同じだけど
  • 状態はIteratorしか持たないからIteratableは再利用可能だよ
• 環境
  • go1.18以上
• パフォーマンス
  • ベンチマークの結果を中心に
  • ベンチマークをアップしてからかな

• Take は件数を指定して先頭から取得する
• TakeWhile は条件を指定して先頭から一致する範囲を取得する

• switchで分岐して初期化している関数とifで分岐して初期化している関数があるが、全てifの分岐に統一する
  • MoveNextとかはパフォーマンス事由でどちらを使うか変えてもよいけど、Iterable作る処理はそこまで回数ないのでなるべく同じ書き方で揃えたい

Github Actionsで以下の辺り？

• fmt
  • go fmtかけて変更ある場合は落とす
• test
• coverage
  • 手間かかりそうなので別issueに切り出した
• static check
  • 何かいいのあれば導入する

RCのイメージ使ってできるかも一応確認、ダメなら正規イメージ出てから

The feature you want to use.

TODO: write later.
Describe the feature name and how feature processes.

What benefit with the feature?

Describe a clear and concise what achive from the feature.
We also welcome to post how to use example code.

Is possible achive alternative by other features in project or its combination?

Describe whether you can achive you want in already implemented another features.
Describe how loss with using another, also.

Others

Add any other context about the feature request here.

Codecov整理して使えるようにする
やり方覚えてなくて大変そうなので #3 から切り出して後付で対応する

Iterator.MoveNext() の条件分岐の書き方に揺れがあるので統一する

if it.it.MoveNext() {
    it.current = it.it.Current()
    return true
}
it.current = zero[T]()
return false

となっているところがあるので、

if !it.it.MoveNext() {
    it.current = zero[T]()
    return false
}
it.current = it.it.Current()
return true

になるように合わせる。
ただしforの利用や複数の条件分岐などで記述が複雑になる場合はそのまま残しておく

• Last は件数を指定して末尾から取得する
• LastWhile は条件を指定して末尾から一致する範囲を取得する

TakeWhileに渡す関数がnilの場合はTakeする条件が常にfalseなので空のIterableを返すように変更する

実装済のそれぞれの機能についてExample用意する

• FromSlice
• FromSliceImmutable
• Filter
• Map
• Concat

Proposal.

Reserach whether needs implement or not Iterator common fields.

What benefit with the proposal?

By implementing some functions, I noticed Iterator has some common items.
If these are defined common struct, Iterator implement is simplify a little.

But, nested struct performance cost is not confirmed, so take benchmark for comparing using struct or not using.

Others

• Filter[T](Iterable[T], func(T) (bool, error)) (Iterable[T], error) の実装

Proposal.

Like strings.Repeat, change so func ends with panic by invalid zero or negative arguments.

Breaking change targets are below.

• panic by negative num
  • Repeat
  • RepeatIterable
  • Take
  • TakeLast
  • Skip
  • SkipLast
• panic by zero
  • Range
    • change interface with no error.

What benefit with the proposal?

Understand easily for arguments ristriction and can approach to golang standard.

Others

strings.Repeat

• 内部でスライスに詰めていく
  • 他にコストがよい実装思いついたら置き換える
• sliceIteratableの場合は独自実装にしたほうがコスト軽くなりそう

• Skip は件数を指定して先頭から除外する
• SkipWhile は条件を指定して先頭から一致する範囲を除外する

単語間違えてたのでまとめて直す _(:3」∠)_

Proposal.

Pull Requestを作るときに必要な確認項目をまとめたテンプレートを追加する。
そのうち種類ごとに分けるかもしれないけどまずは1テンプレート作ってみる。

What benefit with the proposal?

Pull Requestを作る際に記述してほしい事、確認してほしい事を提示できる。

Others

Proposal.

In other collection frameworks, function name that returns last n elements is TakeLast.

What benefit with the proposal?

To easier understand from function name.

Others

• In rxjs
  • https://github.com/ReactiveX/rxjs/blob/master/src/internal/operators/takeLast.ts
• Implement before #83

Proposal.

Verify for introduce Block fixup commit merge.

What benefit with the proposal?

Prevents merge before squash with fixup commits.

Others

初期に出した実装はinterfaceとsliceしかコメント書いてないので、他のexportedな関数にコメントつける

Note: 後から追加の機能はここで対応するのでなく個別のチケット内で書くようにする

• 各Iteratorに処理が終了したかを判別させるフラグを持たせる
  • MoveNextの処理が今は常に上位のIteratorを見てるが大量にIterable重ねると重そうな気がする
• ついでにベンチマーク取り直す
• カバレッジ減ったらテストも合わせて修正する

• Repeat は要素と件数を指定して同じ要素を繰り返して返す
• 今の Repeat は RepeatIteratable に変更する

• mapfuncの戻り値はどうする？
  • slice?
  • Iteratable?
  • 両方作っても良さそう

• MapE[T, R](Iterable[T], func(T) (R, error)) (Iterable[R], error) の実装
• error型はどの内部要素なのかを判別できると良さそうなので、特化型の方が良いかも

• 初期値、最終値、増分を渡して作成
• 増分に0渡された場合の対処
  • (Iteratable[T], error) でよさそう
• 正負で実装変えたほうがよさそう
  • 増分次第では最終値に当たらないと無限ループ起こすので

Proposal.

Add common test case for empty element but no emptyIterable.
The test checks for no panic.
Use test source like below.

itb := gcf.FromSlice([]int{1})
itb = gcf.Filter(itb, func(v int) bool { return false })

What benefit with the proposal?

Since each Iterator does not expect to pass 0 Iterators, it could panic trying to process 0 Iterators.
By passing this test prevent that panic.

Others

emptyじゃない時にパニック起こさない汎用のテストケース作ってソース以外の関数に適用する

Originally posted by @meian in #83 (comment)

Proposal.

• Add pkg.go.dev Reference badge to README
  • [![Go Reference](https://pkg.go.dev/badge/github.com/meian/gcf.svg)](https://pkg.go.dev/github.com/meian/gcf)
• Remove func List from README.

What benefit with the proposal?

Have easy access to standard reference.

Others

Issue立てるときのテンプレートを作成する。
これ以降はなるべくテンプレートに従ったIssueの書き方にする。

• Feature Request
• Bug
• Proposal

最初はこのぐらいあればよいかな。

Iteratorの処理についてはスレッドセーフを考慮しない作りになっているのでその辺りをREADMEに追記する

Proposal.

Apply Go Report Card in CI.

What benefit with the proposal?

Ensuring a certain level of code quality by various static analyzes.

Others

• Current report
  • https://goreportcard.com/report/github.com/meian/gcf
  • gofmt, golint, ineffassign may not be supported Go1.18, so we apply it after supported.
  • supported!!

ソート関連の実装

• Sort, SortDESCの実装
  • Ordered制約かかっている型のみをサポートしたほうがよさそう？
  • OrderedIteratable / OrderedIterator を追加しないとThenBy系は実装できなさそう
  • SortStableの対応はどうしよう？
    • 個別メソッドにするとSort系だけで8個もできる？
• SortBy, SortByDESC, ThenBy, ThenByDESCの実装
  • 内部要素などでソートをしたい時に使うやつ
  • SortBy[T any, K Ordered](itb Iteratable[T], f func(T) K) 辺りのシグネチャで実装するイメージ
• 一旦内部でsliceに戻してソートしてからsliceIterator作って返す？
  • もっと軽くできるイメージがないけど他の実装見て確認してみるかな

• filterのベンチマークを作ったので同じぐらいのデータ量で他のベンチマークを作る
  • ある程度機能が揃ってからでよいかな
• channelベースで実装したときとのパフォーマンス比較
  • 処理速度・CPU・メモリ辺り