From: Akinori MUSHA <knu@...>
Date: 2009-11-12T21:11:21+09:00
Subject: [ruby-dev:39672] Re: [Bug:trunk] Enumerator.new {|y| y << 1 << 2 	<< 3 }

--pgp-sign-Multipart_Thu_Nov_12_21:08:27_2009-1
Content-Type: text/plain; charset=ISO-2022-JP

At Thu, 12 Nov 2009 01:23:56 +0900,
Yusuke ENDOH wrote:
> > 　Yielder/Generator という組合せによる実装は実験的なもので、特に
> > 後者は外部に公開する必要がないので敢えて伏せていました。公開仕様に
> > すると制約になるので、需要が生じるまでは非公開の方がいいのではない
> > でしょうか。
>
> ああ、やっぱりそういう意図なんですよね。そういうことならドキュメントは
> コミットしないでおきます。
>
> ただ、Enumerator.new にちょろっと説明があるとはいえ、Yielder のインス
> タンスはユーザに丸見えなので、Yielder#yield と << まで nodoc というのは
> あまりよくないかなとは思いました。

　こういうときは

class Enumerator
  # ブロックを渡すと(略)インスタンスが生成されて、
  # Enumerator::Yieldable なオブジェクトが渡されて呼ばれるよ
  def initialize
  end

  # レキシカルなコンテクスト外のブロックにyieldするためのモジュール
  # このモジュールは #yield を前提にしているよ
  module Yieldable
    # 渡されたvalueをyieldするよ
    # このモジュールをincludeするクラスが実装するよ
    def yield(value)
      raise NotImplementedError
    end

    # yieldしてselfを返すよ
    def <<(value)
      self.yield(value)
      self
    end
  end

  # :nodoc:
  class Yielder
    def yield(value)
      # ..
    end

    include Yieldable
  end
end

のような構成にすると、クラス名の明文化を避けつつドキュメントする
ことができて、将来の変更に対する制約を回避できるかもしれませんね。

　つまり、ユーザが y.instance_of?(Yielder) などとしだすともう特異
オブジェクトを返すように変えることはAPI変更になってしまいますが、
y.is_a?(Yieldable) と y.respond_to?(:yield) (および :<<)しか仮定
させないことで、 extend Yieldable した特異オブジェクトを返しても
互換性の問題なしというわけです。

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

--pgp-sign-Multipart_Thu_Nov_12_21:08:27_2009-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (FreeBSD)

iEYEABECAAYFAkr7+rsACgkQkgvvx5/Z4e41ZACgsmpDzSic7+wHrpGUU2mYASbS
/bcAoJpJ0ljo3ztkyCbqtcCHQAOvAHah
=wz01
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Thu_Nov_12_21:08:27_2009-1--