[#46329] [ruby-trunk - Feature #7252][Assigned] version number of 2.0 release — "usa (Usaku NAKAMURA)" <usa@...>

26 messages 2012/11/01

[#46350] RubySpecメンテナ — Yukihiro Matsumoto <matz@...>

まつもと ゆきひろです

15 messages 2012/11/02
[#46352] Re: RubySpecメンテナ — Urabe Shyouhei <shyouhei@...> 2012/11/02

On 11/01/2012 07:43 PM, Yukihiro Matsumoto wrote:

[#46414] [ruby-trunk - Bug #7287][Open] please rename atomic.h which conflicts with /usr/include/atomic.h in Solaris10 — "ngoto (Naohisa Goto)" <ngotogenome@...>

10 messages 2012/11/06

[#46434] トラップハンドラで許されない操作はなにか — KOSAKI Motohiro <kosaki.motohiro@...>

GyRCPi46aiRHJDkbKEIKCltCdWcgIzcxMzRdIBskQiRyRDQkWSRGJCQkRj88SiUkSjtFTU1MZEJq

9 messages 2012/11/06

[#46440] [ruby-trunk - Bug #7300][Open] Hash#[] の挙動が 1.9.3 と異なっている — "hsbt (Hiroshi SHIBATA)" <shibata.hiroshi@...>

12 messages 2012/11/07

[#46477] Fwd: [ruby-changes:25559] shugo:r37616 (trunk): * vm_core.h (rb_call_info_t::refinements), compile.c (new_callinfo): — SASADA Koichi <ko1@...>

refinement を導入するときの性能に対する excuse が「method cache に殆どあ

20 messages 2012/11/11
[#46480] Re: Fwd: [ruby-changes:25559] shugo:r37616 (trunk): * vm_core.h (rb_call_info_t::refinements), compile.c (new_callinfo): — Shugo Maeda <shugo@...> 2012/11/11

前田です。

[#46488] Re: Fwd: [ruby-changes:25559] shugo:r37616 (trunk): * vm_core.h (rb_call_info_t::refinements), compile.c (new_callinfo): — SASADA Koichi <ko1@...> 2012/11/12

 ささだです.

[#46491] Re: Fwd: [ruby-changes:25559] shugo:r37616 (trunk): * vm_core.h (rb_call_info_t::refinements), compile.c (new_callinfo): — Shugo Maeda <shugo@...> 2012/11/12

前田です。

[#46493] Re: Fwd: [ruby-changes:25559] shugo:r37616 (trunk): * vm_core.h (rb_call_info_t::refinements), compile.c (new_callinfo): — SASADA Koichi <ko1@...> 2012/11/12

 ささだです.

[#46495] Re: Fwd: [ruby-changes:25559] shugo:r37616 (trunk): * vm_core.h (rb_call_info_t::refinements), compile.c (new_callinfo): — Shugo Maeda <shugo@...> 2012/11/12

前田です。

[#46497] Re: Fwd: [ruby-changes:25559] shugo:r37616 (trunk): * vm_core.h (rb_call_info_t::refinements), compile.c (new_callinfo): — SASADA Koichi <ko1@...> 2012/11/12

(2012/11/12 18:20), Shugo Maeda wrote:

[#46501] Re: Fwd: [ruby-changes:25559] shugo:r37616 (trunk): * vm_core.h (rb_call_info_t::refinements), compile.c (new_callinfo): — Shugo Maeda <shugo@...> 2012/11/12

前田です。

[#46513] Re: Fwd: [ruby-changes:25559] shugo:r37616 (trunk): * vm_core.h (rb_call_info_t::refinements), compile.c (new_callinfo): — Nobuyoshi Nakada <nobu@...> 2012/11/14

なかだです。

[#46509] [ruby-trunk - Bug #7344][Open] gem pristine bigdecimal が失敗してしまう — "hsbt (Hiroshi SHIBATA)" <shibata.hiroshi@...>

31 messages 2012/11/13

[#46520] [ruby-trunk - Bug #7356][Open] ruby-2.0.0-preview1 で adlint-2.6.10 が性能劣化 — "yanoh (Yutaka Yanoh)" <yutaka@...>

11 messages 2012/11/15

[#46647] [ruby-trunk - Bug #7452][Assigned] Main thread is stopped after running finalizers if the main thread has a finalizer — "mrkn (Kenta Murata)" <muraken@...>

8 messages 2012/11/28

[ruby-dev:46494] Refinement仕様

From: Yukihiro Matsumoto <matz@...>
Date: 2012-11-12 08:50:18 UTC
List: ruby-dev #46494
まつもと ゆきひろです

土曜日のRefinement会議で出た宿題について。

以下の仕様候補のうちいずれを選ぶかという話でした。

(a) re-open

一度usingされたモジュール(またはクラス)をre-openした場合、そ
のモジュール/クラスの本体でrefinementが有効かどうか。

(b) inheritance

usingされたモジュールをincludeしたクラス(またはクラス)、およ
びusingされたクラスを継承したクラスの本体でrefinementが有効か
どうか。

上記、(a),(b)ともに定義の字面上usingが登場しない局面で、
refinementが有効かどうかという判断になります。usingが明示的
に登場しないのに挙動が変化することは混乱を呼ぶ可能性がありま
す。また、モジュール・クラスの定義がロードされる順序によって、
挙動が変化してしてしまうことで、更なる混乱の可能性があります。

さらに目に見える範囲にusingがないことで、最適化が難しいという
こともあるでしょう。

(c) module_eval

module_evalを使ったトリックは、松田さんのRubyConf発表でもあ
り、なかなか興味深いテクニックなのですが、その一方、同じコー
ドがrefinement有効で呼び出されるのか確定できず、最適化が難し
い上に、インラインキャッシュと相性が悪いという問題があります。

ちなみに現状では(a),(b),(c)とも有効だが、(c)についてはインラ
インメソッドキャッシュに関連する深刻なバグがあり、r37616で修
正が試みられたが、深刻な速度低下問題によりrevertされた、と認
識しています。合ってる?

で、週末つらつらと考えたのですが、

  * refinementはレキシカルななにかではなく、モジュール・クラ
    スに追加される属性である

という点をより明確にして、(a),(b)ともに有効にしようと思います。
(c)については悩んだのですが、かなり深刻な問題だと思うので、

* module_eval(&b)の形式は禁止(例外)
* またはrefinement状態が異なる状態でのブロックの実行は禁止

のいずれかではどうだろうかと思っています。前者であれば松田テ
クニックが使えないことになるわけで、個人的には後者を望んでい
ますが、前者でも仕方がないと思っています。将来制約緩和の可能
性はあるので。

残る問題はTwitterで、なかださんが指摘したprependとrefinement
の関係です。つまり

 class B
   def foo
     p :B
   end
 end

  module A
    refine B do
      def foo
        p [:refine, :A, :B]
      end
    end
  end

  module C
    def foo
      super
      p :C
    end
  end

  class B
    prepend C
  end

  module D
    using A
    B.new.foo # => なにが出力されるか
  end

という問題です。選択肢としては

(1) refineはprependを含めてそのクラスのメソッドを上書きする
    (現状)。よって出力は[:refine, :A, :B]
(2) refineはprependで修飾される前の基本メソッドを置き換える。

のいずれかですが、私はこれは(1)が望ましいと思います。つまり、
ローカルの指定であるrefinementの方が優先されるべきだと思うか
らです。ただし、[ruby-dev:46477]にある探索手法の提案では、私
が理解する限りでは自動的に(2)の挙動になるので、その辺は検討
の余地があると思います。

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

In This Thread

Prev Next