From: Yukihiro Matsumoto <matz@...>
Date: 2006-02-20T08:48:28+09:00
Subject: [ruby-dev:28342] Re: constant look up order in CVS HEAD

まつもと ゆきひろです

In message "Re: [ruby-dev:28341] Re: constant look up order in CVS HEAD"
    on Mon, 20 Feb 2006 04:18:58 +0900, GOTOU Yuuzou <gotoyuzo@notwork.org> writes:

|例えば、
|
|module M
|  class Config
|  end
|
|  class C
|    p Config
|  end
|end
|
|という場合にrbconfigをロードするかどうかによって動作が変るよ
|うになったのですね。変更前と比べると、他のライブラリの影響を
|より受けやすく、また、この影響は一緒に使ってみるまで分からな
|いためテストでは発見しにくいような気がします。

いいえ、ルールは

  自クラス→スーパークラス(Objectを除く)→外側のクラス(トップを除く)→Object

ですから、上記のプログラムの「p Config」の位置での検索順は、

  class C →  module M → Object

になり、トップレベルにConfigがあるかにかかわらずいつも
M::Configになります。

で、akrさんの指摘した問題のある箇所は、

    class CGIHandler < AbstractServlet
      Ruby = File::join(::Config::CONFIG['bindir'],
                        ::Config::CONFIG['ruby_install_name'])
      Ruby << ::Config::CONFIG['EXEEXT']
>     CGIRunner = "\"#{Ruby}\" \"#{Config::LIBDIR}/httpservlet/cgi_runner.rb\""

のようにトップレベルConfigとWEBrick::Configが混在している場
所だったり、

        class A < Resource
          ClassHash[[TypeValue = 1, ClassValue = ClassValue]] = self # :nodoc:

のように同名の定数が登場するところ(ここで

  左辺のClassValueはResolv::DNS::Resource::A::ClassValue
  右辺のClassValueはResolv::DNS::Resource::IN::ClassValue

)だったりしますので、元々意味のわかりにくいコードであったの
が検出されたということで、長期的には良いことではないかと思い
ます。

                                まつもと ゆきひろ /:|)