[ruby-list:49173] Re: Enumerator#+

At Fri, 1 Feb 2013 08:16:53 +0900,
小田 利通 wrote:
> H.Hiro さん、こんにちは。 小田です。
>
> 》で英語でぐぐってたら、4年ほど前に同じ提案がなされていて、knu氏が提案不採用という裁決を出しています。
>
> 一度議論されて結論が出ていれば、納得です。
> （私のぐるり方が悪く見つけられなかった）

私が当事者ですが、当時も書いた通り「あの演算子があってもいいのに…」と
いう想いは魅惑的で、考えるほどに楽しいです。しかし、「他に定義はありえ
ないか？」「他の演算子やメソッド、姉妹クラスとの整合性は？」「将来的な
拡張の負担とならないか？」のように突き詰めていくことが必要です。先の議
論でも、一貫性、体系性、直感性、実用性など、いろいろな検討要素を挙げま
した。

たとえば、「string1 - string2 が string1.sub(string2, '') 相当だったら
いいのに！直感的でしょ！」と思いついたとしても、「String#delete が一致
した文字すべてを削除するように、 - も gsub ですべて消すべきだろうか？」
とか、「+ の逆操作だとすれば末尾にあるときだけ削除すべきだろうか？」と
か、さらに妄想たくましく、「減算を定義するのなら、いっそ『負の文字列』
を考えてもいいのかもしれない。そうすると、数値のように strings.sort_by
{ |string| -string } で逆順にソートできたりするだろうか…」などなど、考
えは尽きません。

妄想はさておき、演算子メソッドに限らず、機能追加の際にまずまっさきに考
えるべきはユースケースです。誰しも、何かアイデアを思いつくと、その発想
のきっかけになったもの（コード）をベースに語りがちですが、実は、その考
えは横道に過ぎず、最適解、王道はほかにあるということがよくあります。

> 》- Enumeratorを連結するというのが、そんなに普通に使われることなのか判断しかねる
>
> 第１水準、第２水準の漢字の表を作ろうと思って、sjis コードで出力（内部的には
> 後に utf-8 にエンコード）しようとしたときに、 sjis の空いている部分を作るために
> 必要になりました。現実世界には欠番のある列挙は結構あると思います。

TCP/IPのポート番号とか、Unicodeで一定のプロパティを持つ文字の集合とか、
よくありますね。しかし、これは Enumerator#+ があるとうれしい例ではない
と思います。二項演算子が目に優しいのはオペランドが固定個のときですが、
文字コード表から生成した範囲集合のような不定個のものを連結するとなれば
xs.inject(:+) のように書くことになるので、二項演算子の記法としてのメリッ
トが生きません。

このケースについて言えば、おそらく列挙以外にも「ある要素がいずれかの範
囲に含まれるかを効率よく検査する」等の機能も望まれるでしょう。とすれば、
Enumerator にはこだわらずにこんなコンテナを作った方がいいと思います。

	https://gist.github.com/4690485

こうして作った専用のコンテナなら、それこそ + を定義して集合のマージを実
装するなど、気楽に演算を定義できます。

> 》- 現状では、（自前で上記の小田さんのような定義をするのでなければ）一旦to_aしてから連結することになり、処理効率の面でも悪い
>
> ブロックで処理したいことを Proc.new で生成してから、呼び出す方法や、
> [enumurator1, enumurator2, ...].each {|enumurator| enumurator.each {|element| ...
> とする方法もあるけど、スマートじゃないですね。

それを仮に Enumerable#flatten_each とか recursive_each のように名付けれ
ば立派な道具になると思います。ただ、それがあると非常に助かるというユー
スケースがどれくらいあるかですね。

--
Akinori MUSHA / http://akinori.org/