[#28337] constant look up order in CVS HEAD — Yukihiro Matsumoto <matz@...>

まつもと ゆきひろです

15 messages 2006/02/18
[#28338] Re: constant look up order in CVS HEAD — Tanaka Akira <akr@...17n.org> 2006/02/19

In article <1140229116.805371.31930.nullmailer@x31.priv.netlab.jp>,

[#28341] Re: constant look up order in CVS HEAD — GOTOU Yuuzou <gotoyuzo@...> 2006/02/19

In message <87lkw8xfay.fsf@m17n.org>,

[#28342] Re: constant look up order in CVS HEAD — Yukihiro Matsumoto <matz@...> 2006/02/19

まつもと ゆきひろです

[ruby-dev:28342] Re: constant look up order in CVS HEAD

From: Yukihiro Matsumoto <matz@...>
Date: 2006-02-19 23:48:28 UTC
List: ruby-dev #28342
まつもと ゆきひろです

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

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

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

In This Thread