[#23884] Ruby 1.8.2 preview1にむけて — matz@... (Yukihiro Matsumoto)

まつもと ゆきひろです

34 messages 2004/07/13
[#23917] Re: Ruby 1.8.2 preview1にむけて — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2004/07/16

山本です。

[#23920] Re: Ruby 1.8.2 preview1にむけて — "NAKAMURA, Hiroshi" <nakahiro@...> 2004/07/16

なひです。

[#23922] ruby 1.8.2 preview1 — matz@... (Yukihiro Matsumoto)

まつもと ゆきひろです

27 messages 2004/07/16

[#23995] String#each -> String#each_char — Shugo Maeda <shugo@...>

前田です。

27 messages 2004/07/30
[#23996] Re: String#each -> String#each_char — matz@... (Yukihiro Matsumoto) 2004/07/30

まつもと ゆきひろです

[#23997] Re: String#each -> String#each_char — "U.Nakamura" <usa@...> 2004/07/30

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

[#23999] Re: String#each -> String#each_char — matz@... (Yukihiro Matsumoto) 2004/07/30

まつもと ゆきひろです

[#24000] Re: String#each -> String#each_char — "U.Nakamura" <usa@...> 2004/07/30

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

[#24005] Re: String#each -> String#each_char — Minero Aoki <aamine@...> 2004/07/31

青木です。

[#24012] Re: String#each -> String#each_char — Shugo Maeda <shugo@...> 2004/08/01

前田です。

[#24014] Re: String#each -> String#each_char — Minero Aoki <aamine@...> 2004/08/02

青木です。

[ruby-dev:23978] Re: 引数の上書きとsuper

From: SASADA Koichi <ko1@...>
Date: 2004-07-27 09:10:53 UTC
List: ruby-dev #23978
  matz@ruby-lang.org (Yukihiro Matsumoto) wrote :
    [ [ruby-dev:23973] 引数の上書きとsuper ]
    at Tue, 27 Jul 2004 14:43:38 +0900

 ささだです.
 再送します.

---- 

> と呼び出した時には[100,2,3]を出力します。つまりこれは引数を
> 上書きするとsuperは上書きされた引数を渡してしまうということ
> です。

 この例では [200, 2, 3] ですね.


> これはいかにもまずいので、引数に代入してもsuperのデフォルト
> で渡される引数は元のまま渡されることにしようと思います。
> 
> 反対の人はいますか。

 パフォーマンスの点で反対します.

1. 引数のリストのコピーが,すべてのメソッド呼出し毎に必要になる

 ただでさえ遅いメソッド呼び出にとって,とても大きな速度的な
欠点になると思います.


yarv-dev での,

> メソッド呼び出しごとにコピーしなくても、引数に代入した時点で
> オンデマンドにコピーすればよいのでは、というか手元ではそう実
> 装しちゃいました。

という解決方法では,

a. 引数と他のローカル変数アクセスの区別が必要になる
b. コピー前とコピー後を区別する必要がある
c. 結局引数に代入することを多用する人(例:私)には遅いまま

 という点で嫌です.





 対案としては(無引数 super を zsuper と呼称します),

A. zsuper を無くす

 私は好きだし,互換性の問題から無くせないですよねぇ.


B. "現在の仕様" を続ける

 引数に代入するほうが悪い.
 仕様に明記すれば問題ないのでは?

http://www.ruby-lang.org/ja/man/index.cgi?cmd=view;name=%A5%E1%A5%BD%A5%C3%A5%C9%B8%C6%A4%D3%BD%D0%A4%B7#super
(引用)
----------------------------------------------------------------
例:

class Foo
  def foo(arg=nil)
    p arg
  end
end

class Bar < Foo
  def foo(arg)
    super(5)       # 5 を引数にして呼び出す
    super(arg)     # 5 を引数にして呼び出す
    super          # 5 を引数にして呼び出す super(arg) の略記法
    arg = 1
    super          # 1 を引数にして呼び出す super(arg) の略記法
    super()        # 引数なしで呼び出す
  end
end
Bar.new.foo 5
----------------------------------------------------------------

注: この例は私が追加したんじゃないっす


 モデルとしてこんかいの修正案が自然である,という議論については,

- 数年この仕様で誰も困らなかった

 という,消極的な反論をしてみます(全然説得力がない orz)


C. 静的解析による解決,および eval による zsuper を禁止

 これは,コードを静的解析して,そのメソッド中で zsuper が現
れた場合に,

C1. そのメソッドで常に引数リストのコピーをとるようにする
C2. または,最初に引数への代入が行われる前にコピーを取る

 と対処するという案です.

def m a, b
  super  # a,b を利用
  a = 10 # この行を行う前に引数リストをコピー
  super  # コピーした引数リストを利用(バイトコードにするなら,多分別命令)
end

 と思ったけど,C2は eval("a = 10") に対応できないですね.
C2は没.

 eval による zsuper の禁止は,この解析が行えないからなのです
が,eval による解析を行った時点で,必要ならリストをコピーする
というのは考えられます(しかし,リストをコピーしたかどうかの
判断をしなければいけないのはちょっと嫌)


D. 引数代入が起こる後の zsuper 禁止(eval 無視)

def m a,b
  ...
  super # ok
  a = 1
  super # ng(例外?) 静的解析による
end


 とか,考えたのですが,どうでしょうか.
 本命B,次点C.

 C, D は,eval 内での zsuper の禁止が必要になります(あとは
処理系努力).しかし,また変な規則が増えるのは不味いような気
もします.


 本音は,あまり利用されない(だろう) zsuper のために,普遍
的な部分で大きなコストを払いたくない,です.


-- 
// SASADA Koichi at atdot dot net
//

E. 引数への代入を認めない

 私の案じゃないですけど.



// 協力: #rrr のひとたち

In This Thread