[ruby-dev:8809] Re: [REQ] Array#each{|a,b,...|}, Array#shift/pop(num)

西＠九大です。
＃あけおめです。長いです。

From: [e-mail] (Yukihiro Matsumoto)
> 語彙については「できないもの」に比べて優先度が下がる傾向があ
> ります。特に曖昧でない名前が必要です。pop(3), shift(3)がそう
> かというと少し躊躇があります。

了解しました。「語彙＜機能」は同感です。

> 標準のeachにはこの機能は追加しません。each全体の挙動が予想し
> にくくなるので。別の名前でこれを標準装備するかどうかは、世論
> によるということで。

もちろん、「別名で」です。エンバグ以外にも、使用頻度が非常に高いであろ
う基本メソッドである本来の each が今回の件で(少しでも)遅くなったりする
のは嫌なので。

今回に関して言えば、その「多引数の each」があると大変便利です。でも、
他に「ある Collection で、規則性を持つような要素列」というよい例が思い
つかないので、世論に訴えかけるのは難しそうです。

しかし、簡単なちょっとしたプログラム(eRuby とか)を書く時など、わざわざ
新しいクラスを作るのも敷居が高い、と感じる場合には、あると便利な機能だ
と思います。

> これはあおきさんと西さんでいろいろやってもらって勝った方が生
> き残ると言うのはどうでしょう？ メソッド進化論。^^;;;

アムロ、行きまーす！(涙を流しながら)


From: Minero Aoki <[e-mail]>
> ぼくは splice をそのまま導入することには賛成できません。
> 理由は以下の4点です。

大筋は理解できたのですが、気になる所を質問させて下さい。

> 2  いま必要とされているのは splice のうち破壊的抽出の機能で
>    それ以外の機能(あとに値を代入)を導入する理由はない

これは「2つの機能を持つ(1つの)メソッドより、それぞれの機能を持つメソッ
ドを(2つ)作った方が汎用的」という意味ですね？それなら理解できます。

> 3  delete_at(長さ1の破壊的抽出) と array[index]=val(長さ1の代入)は
>    別のメソッドとして用意されているのだから、長さを持つ抽出と
>    代入も別のメソッドとしてあるほうがよい

これは頂けません。好意的に解釈すれば「現在の Ruby の流儀に従うべきだ」
という事ですが、「もっとよい流儀があるのでは？」という問いには無力だか
らです。「抽出と代入」がワンセット(のメソッド)の方がよいのか？に関する
答えはまだ不明ですが、それ以前に成立する疑問です。

> 4  要素をセットすると同時にその部分の要素を取りだすメソッドは
>    他にはない

これも、上と同じ疑問を持ちます。「ないので？」という感じです。「ないの
で、あると大変便利」かもしれない。「他の(Ruby の)メソッドと比べて異質」
というのであっても、その異端と思われた方が実は「高き良き処」かもしれな
い。と思うのです。

繰り返しになりますが、「抽出と代入」をまとめる方がいい事なのかは自分の
中でもまだ答えがでていません。でも、「今はこうだから」という理由でそれ
以上考えないのも危険(未定義語)だと思うのです。

どんどん仕様が変わるのも考え物ですが、「破壊なくして建設なし」とも言い
ますし(言わない？)、もっとよい物であれば、思いきって変えるのもいいと思
います。ruby-xxx でのどなたの言葉だったか忘れましたが、それを誇張して、
以下のように思っています。

今後 Ruby が世界規模で普及し、プログラミングの公用語となるくらいまで発
展した時の事を考えると、現在はまだまだ黎明期である。多少の互換性は無視
してでも、その時に素晴しいものになっているように今考えるべきである、と。

私は常々こういう風に考えているので、いつも「過激」な提案ばかりしてるよ
うにも見えるかもしれませんが、「いたずらにメソッドを増やす」事を目的と
した訳ではないというのを御理解の上、お付き合い下されば幸いです。

> 名前は exclude でなくてもいいですが、
> こういう働きをするメソッドはぜひ欲しいです。

「抽出と代入」に関しては、多分、使用頻度と関係していると思います。抽出
後に代入する事が多ければ、両方を具備する単一メソッドとして存在した方が
便利でしょうし、perl::splice はそういう思想の元で作られたのではないか
と推測しています。

なのですが、確かに、それ以前に「破壊的抽出のみ」のメソッドはあって然る
べしだと思いますので、当然、Array#exclude(extract?) には賛成です。

> pop は「最後部の要素をとりのぞく」という目的を持つメソッドであって、
> pop(3) というのは「3回最後部の要素をとりのぞく」と解釈するほかありません。
> しかし、Ruby のライブラリにはイテレータを使わずに「x 回 〜 する」という
> 意味をもつメソッドは存在せず、pop(3) の働きは非常に想起しにくいからです。

これに関しても、上と同意見です。従来の Ruby ライブラリの範疇では想起さ
れ難いものであっても、それが大変便利であれば取り込んで行き、結果的に
Ruby ライブラリに正のフィードバックが成されれば最高だと思います。

From: [e-mail]
>   array.pop は現状は最後尾にあったオブジェクトそのものを返します
> が、array.pop(N) だとたぶん Array になると思います。そこのギャッ
> プはどうしたもんでしょうか。

こちらに関しては、ギャフン！です。確かに、ギャップがあります。ただ、
同じくなかださんの、

>   配列は多重代入などで特別扱いされることが多いからだと思うんです
> が。

が解決策(というか屁理屈)になる気がします。全く違うクラスのインスタンス
が返ってくるのであれば、気持ち悪いですが、obj と [obj,..] であれば、そ
れ程気持ち悪くないです。何となく多重代入にするだけで、柔軟に対応できる
ので、特に Ruby においては、そんな気がしてます。

  obj = array.pop
  obj1,obj2,... = array.pop(n)

というのが、個人的には自然に受け入れられるので、あってもよいと思ってい
ます。ただ、上のギャップの存在は確かであり、それにを覆す正当性を持った
反論もできないので、「語彙(alias)」とは違う(押し切るのは無理)、素直に 
Array#extract 等に従うべき、という気もしています。既に弱気です。はい。

------------------------------------------------------------------
九州大学大学院システム情報科学研究科 情報工学専攻 博士後期課程三年
      西 和則   ( e-mail: [e-mail] )
------------------------------------------------------------------