Feature #4043: グローバル関数current_classの提案

• Status: Rejected
• Assignee: matz (Yukihiro Matsumoto)
• Target version: 2.0.0

[metanest (Makoto Kishimoto)]

=begin
カレントクラス（MRIの内部でいうところのcref）をRubyから調べられるメソッドcurrent_classを提案します。
グローバル関数（Kernelのプライベートメソッド）にする理由は、self（ないしなんらかのオブジェクト）とは関係ない値を返すメソッドであるため、です。
ユースケースですが、例えば以下のようにして、モジュールのinstance_evalとmodule_evalの違いをRubyプログラマが確かめることができ、Rubyの理解に役立ちます。

$ irb19
irb(main):001:0> module M ; end
=> nil
irb(main):002:0> M.instance_eval { current_class }
=> #Class:M
irb(main):003:0> M.module_eval { current_class }
=> M

差分を付けますが、クイックハックですので修正が必要かと思います。

diff --git a/object.c b/object.c
index 75192c1..82ad85a 100644
--- a/object.c
+++ b/object.c
@@ -2408,6 +2408,13 @@ rb_f_array(VALUE obj, VALUE arg)
return rb_Array(arg);
}

+VALUE rb_vm_cref_cls(void);
+static VALUE
+rb_f_current_class(VALUE obj)
+{

• return rb_vm_cref_cls();
  +}

/*

• Document-class: Class

@@ -2588,6 +2595,8 @@ Init_Object(void)
rb_define_global_function("String", rb_f_string, 1);
rb_define_global_function("Array", rb_f_array, 1);

• rb_define_global_function("current_class", rb_f_current_class, 0);
• rb_cNilClass = rb_define_class("NilClass", rb_cObject);
  rb_define_method(rb_cNilClass, "to_i", nil_to_i, 0);
  rb_define_method(rb_cNilClass, "to_f", nil_to_f, 0);
  diff --git a/vm.c b/vm.c
  index 980e7ea..dcc43df 100644
  --- a/vm.c
  +++ b/vm.c
  @@ -819,6 +819,12 @@ rb_vm_cref(void)
  return vm_get_cref(cfp->iseq, cfp->lfp, cfp->dfp);
  }

+VALUE
+rb_vm_cref_cls(void)
+{

• return rb_vm_cref()->nd_clss;
  +}

#if 0
void
debug_cref(NODE *cref)
=end

[matz (Yukihiro Matsumoto)]

=begin
まつもと ゆきひろです

In message "Re: [ruby-dev:42564] [Ruby 1.9-Feature#4043][Open] グローバル関数current_classの提案"
on Thu, 11 Nov 2010 12:50:42 +0900, Makoto Kishimoto [e-mail] writes:

|カレントクラス（MRIの内部でいうところのcref）をRubyから調べられるメソッドcurrent_classを提案します。
|グローバル関数（Kernelのプライベートメソッド）にする理由は、self（ないしなんらかのオブジェクト）とは関係ない値を返すメソッドであるため、です。

そういう機能の追加には賛成しますが、グローバル関数は増やした
くありません。どうするのがよいでしょうね。

=end

[metanest (Makoto Kishimoto)]

=begin
きしもとです

|カレントクラス（MRIの内部でいうところのcref）をRubyから調べられるメソッドcurrent_classを提案します。
|グローバル関数（Kernelのプライベートメソッド）にする理由は、self（ないしなんらかのオブジェクト）とは関係ない値を返すメソッドであるため、です。

そういう機能の追加には賛成しますが、グローバル関数は増やした
くありません。どうするのがよいでしょうね。

さがしてみたところ、Module の特異メソッドに、レシーバとは関係ない、
現在のコンテキストについて動作するものがありました。

なので、Module の特異メソッドではどうでしょうか？

=end

[matz (Yukihiro Matsumoto)]

=begin
まつもと ゆきひろです

In message "Re: [ruby-dev:42834] Re: [Ruby 1.9-Feature#4043][Open] グローバル関数current_classの提案"
on Tue, 21 Dec 2010 11:21:32 +0900, "KISHIMOTO, Makoto" [e-mail] writes:

|> そういう機能の追加には賛成しますが、グローバル関数は増やした
|> くありません。どうするのがよいでしょうね。
|
|さがしてみたところ、Module の特異メソッドに、レシーバとは関係ない、
|現在のコンテキストについて動作するものがありました。
|
|なので、Module の特異メソッドではどうでしょうか？

その場合、Module.current_class という名前になるんですかね。

=end

[metanest (Makoto Kishimoto)]

=begin
きしもとです

|> そういう機能の追加には賛成しますが、グローバル関数は増やした
|> くありません。どうするのがよいでしょうね。
|
|さがしてみたところ、Module の特異メソッドに、レシーバとは関係ない、
|現在のコンテキストについて動作するものがありました。
|
|なので、Module の特異メソッドではどうでしょうか？

その場合、Module.current_class という名前になるんですかね。

Module.current_module のほうがいいですね。Module を指すことがあること
とも一致します。

元々「メタプログラミングRuby」でそう呼んでるから、という理由だけで命名
してますので、そちらとズレる、というのが問題点と言えば言えそうです。

=end

[matz (Yukihiro Matsumoto)]

=begin
まつもと ゆきひろです

In message "Re: [ruby-dev:42838] Re: [Ruby 1.9-Feature#4043][Open] グローバル関数current_classの提案"
on Tue, 21 Dec 2010 17:37:16 +0900, "KISHIMOTO, Makoto" [e-mail] writes:

|> その場合、Module.current_class という名前になるんですかね。
|
|Module.current_module のほうがいいですね。Module を指すことがあること
|とも一致します。
|
|元々「メタプログラミングRuby」でそう呼んでるから、という理由だけで命名
|してますので、そちらとズレる、というのが問題点と言えば言えそうです。

current_moduleという名前なのにクラスを返すこともあるというの
はやや抵抗がありますね。current_classという別名を用意しても
良いのですが、他にアイディアはありませんかね。

=end

[keiju (Keiju Ishitsuka)]

=begin
けいじゅ＠いしつかです.

In [ruby-dev:42845] the message: "[ruby-dev:42845] Re: [Ruby
1.9-Feature#4043][Open] グローバル関数current_classの提案", on Dec/22
01:35(JST) Yukihiro Matsumoto writes:

まつもと ゆきひろです

current_moduleという名前なのにクラスを返すこともあるというの
はやや抵抗がありますね。current_classという別名を用意しても
良いのですが、他にアイディアはありませんかね。

モデリング界では,

descriptor

を使っています. instance との対語として使います. インスタンスがクラス
のインスタンスに限らないのでそのような呼び名が出てきたんだと思います.
まあ, 今回の理由と同じでは?

__
---------------------------------------------------->> 石塚 圭樹 <<---
---------------------------------->> e-mail: [e-mail] <<---

=end

[kosaki (Motohiro KOSAKI)]

=begin

current_moduleという名前なのにクラスを返すこともあるというの
はやや抵抗がありますね。current_classという別名を用意しても
良いのですが、他にアイディアはありませんかね。

モデリング界では,

descriptor

を使っています. instance との対語として使います. インスタンスがクラス
のインスタンスに限らないのでそのような呼び名が出てきたんだと思います.
まあ, 今回の理由と同じでは?

小崎です

個人的な経験ですが、descriptorという用語はUnixのファイルディスクリプタの
イメージがとても強いらしく違う意味で使おうとすると強い抵抗にあいました。今でも事情はあんまり変わっていないのではないかしらん

=end

[usa (Usaku NAKAMURA)]

=begin
こんにちは、なかむら(う)です。

In message "[ruby-dev:42847] Re: [Ruby 1.9-Feature#4043][Open] グローバル関数current_classの提案"
on Dec.22,2010 09:37:33, [e-mail] wrote:

個人的な経験ですが、descriptorという用語はUnixのファイルディスクリプタの
イメージがとても強いらしく違う意味で使おうとすると強い抵抗にあいました。今でも事情はあんまり変わっていないのではないかしらん

私はUnix界の人じゃないので抵抗感が薄いだけかもしれないですけ
ど、Moduleクラスの特異メソッドであるなら Module. が頭に毎回付
くわけなので、ファイルディスクリプタとは絶対に違うものだよ感
出まくりだから問題ないんじゃないでしょうか。

それでは。

U.Nakamura [e-mail]

=end

[usa (Usaku NAKAMURA)]

=begin
こんにちは、なかむら(う)です。

In message "[ruby-dev:42845] Re: [Ruby 1.9-Feature#4043][Open] グローバル関数current_classの提案"
on Dec.22,2010 01:35:44, [e-mail] wrote:

current_moduleという名前なのにクラスを返すこともあるというの
はやや抵抗がありますね。current_classという別名を用意しても
良いのですが、他にアイディアはありませんかね。

単に Module.current というのが真っ先に脳裏に浮かびました。
あまりに一般的に過ぎるかという気はするのですが、いちおう候補
に出しておきます。

それでは。

U.Nakamura [e-mail]

=end

[tarui (Masaya Tarui)]

=begin
たるいです。

ユースケースがRubyの理解という事だし、どこの所属かを考えたら

RubyVM.current_class

が良かったりしませんか？
候補の一つとして。

--
樽家昌也(Masaya TARUI)
No Tool,No Life.

=end

[matz (Yukihiro Matsumoto)]

=begin
まつもと ゆきひろです

In message "Re: [ruby-dev:42850] Re: [Ruby 1.9-Feature#4043][Open] グローバル関数current_classの提案"
on Wed, 22 Dec 2010 12:57:26 +0900, Masaya TARUI [e-mail] writes:

|ユースケースがRubyの理解という事だし、どこの所属かを考えたら
|
|RubyVM.current_class
|
|が良かったりしませんか？
|候補の一つとして。

なんとなくRubyVMってのはVM固有の機能を保持してて欲しいと思い
ます。メソッドの定義先というのは個別のVMに依存する機能ではな
いわけで。

=end

[tarui (Masaya Tarui)]

=begin
たるいです。

個人的にはRubyVMって一般的過ぎてもう少し抽象的なもの、つまり
「RubyのVMが持っているべき特徴」 を示すイメージなのですが、
あくまでYARVを指すことには変わりないという事ですね。

一つ、一般的な実行環境を示すモジュールを用意して幾つか要素をその中に
押し込めたい気がしますが、いまここでそれをいうのも大げさだと思うので、、

Module.current

に一票に変えておきます。

2010年12月22日13:28 Yukihiro Matsumoto [e-mail]:

なんとなくRubyVMってのはVM固有の機能を保持してて欲しいと思い
ます。メソッドの定義先というのは個別のVMに依存する機能ではな
いわけで。

--
樽家昌也(Masaya TARUI)
No Tool,No Life.

=end

[matz (Yukihiro Matsumoto)]

=begin
まつもと ゆきひろです

In message "Re: [ruby-dev:42861] Re: [Ruby 1.9-Feature#4043][Open] グローバル関数current_classの提案"
on Thu, 23 Dec 2010 12:36:51 +0900, Masaya TARUI [e-mail] writes:

|個人的にはRubyVMって一般的過ぎてもう少し抽象的なもの、つまり
|「RubyのVMが持っているべき特徴」 を示すイメージなのですが、
|あくまでYARVを指すことには変わりないという事ですね。

そうですね。たとえばVMのないRuby実行環境もありえるわけで。

=end

[metanest (Makoto Kishimoto)]

• File patch-current-class patch-current-class added

=begin
Module.current に +1

新しいパッチ作りました
=end

[metanest (Makoto Kishimoto)]

きしもとです

この件、現状としては、現在のカレントクラス（cref）を返す、Module の
特異メソッド Module.current の提案、となっているつもりですが、
採用を妨げるものとしては何がありますでしょうか？

[shyouhei (Shyouhei Urabe)]

Makoto Kishimoto wrote:

採用を妨げるものとしては何がありますでしょうか？

やっぱ名前じゃないですかねえ。機能に反対している人は少ないように思われます。

[metanest (Makoto Kishimoto)]

きしもとです

On Wed, 15 Feb 2012 18:05:12 +0900
Shyouhei Urabe [e-mail] wrote:

Issue #4043 has been updated by Shyouhei Urabe.

Makoto Kishimoto wrote:

採用を妨げるものとしては何がありますでしょうか？

やっぱ名前じゃないですかねえ。機能に反対している人は少ないように思われます。

Feature #4043: グローバル関数current_classの提案
https://bugs.ruby-lang.org/issues/4043

さがしてみたところ Module.current で反対意見は見つからないようですし、
見た記憶もないです。

名前（というか提案当初はグローバル関数にすること）を問題にされたのは
まつもとさんだったと思うのですが、Module の特異メソッド Module.current で、
何か問題はありますでしょうか＞まつもとさん

[mame (Yusuke Endoh)]

• Status changed from Open to Assigned
• Assignee set to matz (Yukihiro Matsumoto)

[metanest (Makoto Kishimoto)]

• File No4043.pdf No4043.pdf added

[ruby-dev:45708] コンペ向けの資料を添付

[mame (Yusuke Endoh)]

受け取りました。具体的なユースケースが書いてないので、そこでひっかかってしまうかも。
「まつもとさんは機能自体には賛成していて、名前の議論だけとなっている」と明示するとよいかも。

[mame (Yusuke Endoh)]

• Status changed from Assigned to Rejected

きしもとさん

7/21 の開発者会議にて、残念ながらこの機能は不採択と判定されました。

以下の 3 つの理由によります。

• 「Ruby の理解が進む」というユースケースは弱い

• Module のクラスメソッドはいまいち (Module.nesting で後悔したそうです)

• implementation detail なので他実装で同等に実装できないかもしれない

  • 具体的には mruby で困るらしい

--
Yusuke Endoh [e-mail]