[ruby-dev:1627] Re: [BUG] String.dup

けいじゅ＠日本ラショナルソフトウェアです.

In [ruby-dev :01616 ] the message: "[ruby-dev:1616] Re: [BUG]
String.dup ", on Mar/09 15:39(JST) Yukihiro Matsumoto writes:

>まつもと ゆきひろです

>|私はsuperが本質的な問題になっていると気づくまでだいぶかかってしまいま
>|した. 構造の互換性をチェックする方法に目がいっていたもので(^^;;;
>
>まず最初に「私が1.1b9以降にこの問題に関して行ったこと」を書
>いておきます．まずクラスにインスタンスが通常のオブジェクトで
>ないことを示す1bitのフラグを用意して，すべての組み込みオブジェ
>クトに関してこのフラグを明示的にセットしました．

(中略)

>これらによって問題のほとんどが解消されます．

たぶん, 現在のところはそうだと思います.

>   拡張モジュールで
>   T_DATAなインスタンスを作るクラスを
>   Objectのサブクラスとして定義して
>   そのクラスのインスタンスが一つも定義される前に
>   例の方法(def new; super; end)を使って

>インスタンスを生成されちゃった場合ですが，これは
>
>  * ここまでされると仕方がない

まあそれでも良いと思います, でも, 落ちちゃうのはどうなんでしょ?

>  * T_DATAなクラスはDataのサブクラスにするよう指導する

Numericの例でも出ましたがDataのサブクラスにできないような場合は良くあ
りますよね.

他にも気づいた問題を.

1. 上記の方法はnewにしか対応していない. 
2. 上記の方法は, ObjectのサブクラスとしてPrimitiveがある場合にしか対応
   していない. つまり, あるPrimitiveに別のPrimitiveをサブクラスとして
   定義した場合の対応ができていない.

例えば, C++のクラスをrubyに実装しようとしたとします.

  class Foo {
    int foo;
  public:
    Foo();
  };
  class Bar :public Foo {
    int bar;
  public:
    Bar();
  };

  cFoo = rb_define_class("Foo", cObject);
  cBar = rb_define_class("Bar", cFoo);

Foo.new, Bar.newは各々のコンストラクタFoo(), Bar()を呼ぶようにします.
そうすると,
  def Bar.new; super; end

と再定義されるとまずいことが起こります.

さらに, これはnewの問題でしたが, サブクラスでオーバロードしているメン
バ関数がある場合も同じ問題が起こる可能性があります.

C++は絶対対応しないっていうなら別ですが(^^;;; Cの場合でも似たような
状況は起こりうると思います. 

# 例えばCXを拡張モジュールで実装するとか(^^;;; 内輪の話しですいません
# (__;;;

>|(案2) メソッドそのものの属性として super_undefされているかどうかの状態
>|      を持たせる. 
>まあ，これは無意味ではないですよね．実装もそんなに大変ではな
>いです．

ですね.

>|(案4) クラスのViewを導入する. super_undefはそのクラスから上位のクラス
>|      がどのように見えるメソッドを変更する手段です. クラスのviewを導入
>|      して, 下位のクラスからはviewを通して見えるようにすれば良いかなと
>|      思います. 
>
>えーと，viewって？ ^^;;;

>|(案4)のviewは, 松本君が大学時代やっていた研究課題でしたよね? ですので, 
>|rubyに導入するのも悪くないかなと(^^;;; ただ, だいぶ追加機能が発生しま
>|すが...
>
>良く覚えてましたね．そんなこと．^^;;;

でしょ(^^;;;

>私の研究していたview(profileって名前でしたが)は静的型のある
>言語におけるクラスの外部仕様のサブセットでしたから，ここでの
>viewとはちょっと，というかだいぶん違いますよね．Javaにおける
>インターフェースに近いイメージですか．もう10年くらいの話になっ
>ちゃいますが．

そうですか... 似ていると思うんだけどなあ... クラスの外部仕様のサブセッ
トですから...

>|効果はないのですが, 元々の用途は上位クラスで定義されているメソッドを見
>|えなくするための機能なので, undefをsuper_undefと再定義しても全然問題な
>|いと思うのですが?
>|
>|# メソッドを消去するのはModule#remove_methodでした.
>
>まずそもそもsuper_undefってナニ？ って疑問があるんですが…．
># 最初の例に出て来たのは super_redef だし

>で，本来の話題に帰ると，元々の問題は一応の解決を見ちゃったん
>で，今回提示されたfinalとsuper_undef/super_redefとviewがそれ
>ぞれruby的にどのような意味を持つのか，採用すべきなのか，とい
>う話に移りたいんですケド．

super_undefの良いところ::

1. super_undefは, まだ, 解決できていない部分まで解決することが可能です.

ただ, この様な問題を解決するための機能ですので, 今の対応で十分であると
いうなら, 採用する理由はだいぶなくなります.

意味的にはメソッドの実装上の互換性を宣言するための機能なのですが, 通常
は今のundefとオーバーロードの機能さえあれば十分です. その機能だけで, 
対応できないのは, 意図しない再定義が行なわれた場合ですが, それで困る
(気分が悪い)のはPrimitiveのクラスの場合だけでしょうから.

2. undefの機能をこれと置き換える.

super_undefをundefとして採用することは, それなりに意味があると思います.
undefにあるがsuper_undefにない様な機能でこまることってないと思いますか
ら. さらに, 採用すると(1)の機能がおまけでついてきます(^^;;;

viewの方もsuper_undefと目的は同じですよね. ただ, もうちょっと大がかり
になっていますが. その他の利点については, viewの利点は松本氏の方が詳し
いでしょう(^^;;;

__
................................石塚 圭樹＠日本ラショナルソフトェア...
----------------------------------->> e-mail: [e-mail] <<---