From: "NARUSE, Yui" Date: 2009-05-10T08:53:31+09:00 Subject: [ruby-dev:38402] Re: Enumerable#gather_each 成瀬です。 Akinori MUSHA wrote: > At Sun, 10 May 2009 06:00:08 +0900, > matz wrote: >> In message "Re: [ruby-dev:38394] Re: Enumerable#gather_each" >> on Sat, 9 May 2009 15:53:22 +0900, ujihisa writes: >> >> |一度に二つの手続きを渡すのではなく、 >> |一つのブロックを受け取りEnumeratorを返すgatherと、 >> |従来のeachに分けた方が自然になるのではないでしょうか。 >> >> 私もそう思います。ただ、Enumerableから「条件を満たす限り連続 >> した要素をまとめる」ことをgatherと呼ぶことになんとなく満足で >> きません。gatherという単語からは全体から集めるような印象を受 >> けませんか？ 私だけの感覚でしょうか。 > > 　最初に提案を見て split_by, slice_at, group_until のような名前を > 思い付きましたが、そうして名前を付けてみると、件の挙動にぴったり > 来る名前がないというよりむしろ、それらの名前から想起される機能が > ある程度の幅を持つということが本質なのではないかと気づきます。 gather_byとかsplit_before/afterとか色々悩んだんですが、 これの動きって、divide lines according to proc's return valueじゃないですかね。 つまり、divide_eachとか。 集めると言うよりも、分けるイメージ > 　すなわち、田中さんも触れた通り、ヘッダ行の場合はそこから始まり、 > フッタ行の場合はそこで終わり、区切り行の場合は読み捨てる、という > ような複数の要求が想定でき、それら使い分けができる柔軟性が必要 > なのではないかということです。 > >> とはいえ、[ruby-dev:38399]のbufferというのも、気持ちは分かる >> んですが、ちょっと違うような気がします。柔軟性は高いんですが、 >> なんか内臓が見えてる気がして。 > > 　内臓というのはどのあたりのことでしょうか。すっきりしていると > 思うんですが。Ruby って大体の部分において内臓は見られますよね。 わたしもバッファを用意してーというのは考えたのですが、 田中さんのgather_eachで可能なことが、 gather_eachより複雑になってしまったらダメなんじゃないですかね。 田中さんのgather_eachでできることは、これ以上概念を増やさず ほぼ同等の記述量でこなせつつ、自由度もあげられないといけないのかなと。 RubyなんでBufferみたいな概念を導入しても意外とすっきりするんですが、 そこで甘えちゃいけないんじゃないかと思うのですよ。 # というか、これってバッファは別に提供して、 # Enumerable版injectでやるべきな気も > なお、複数行をまとめる方法として使いそうなものは、まとめる先 > 頭要素を検出する方法を指定するとか、他にもいくつかあるように > 思います。たとえば ChangeLog や mbox を扱うのには、先頭要素 > を指定するのがいいでしょう。そういうものはまた別のメソッドと > して作るのがいいのではないかと思います。 で、考えたのですが、ChangeLogやmboxの場合に対応するには、 直前の要素の分類結果がわかればそれで足りるんじゃないですかね。 結局これらは、 * 特定の要素は自分が分類結果 * それ以外は直前の分類結果と同じ というルールなので、 arg = lambda {|l, current| l =~ /^\S/ ? self : current } みたいにすればよいかなぁと。 これならば田中さんのgather_eachで可能だったことは、 currentを読み捨てればいいだけなので全く同じコードで可能になります。 -- NARUSE, Yui