Menu
▾
▴
Re: [ruby-gnome2-devel-ja] Re: =?ISO-2022-JP?B?R0xpYjIbJEJGSRsoQg==?= =?ISO-2022-JP?B?GyRCJHMkRyRfJF4kNyQ/GyhC?=
|
From: Masao M. <mu...@hi...> - 2002-06-17 15:36:32
|
むとうです。
まずはシンプルにして頭の中を整理したいなと。
On Mon, 17 Jun 2002 03:52:06 +0900
Masahiro Sakai <s01...@sf...> wrote:
> さかいです。
(略)
> > rbglib.c:
> > 前から疑問だったのですが...gErrorって使っていないですよね。
> > もし使っていないようだったら削除しちゃいませんか？
> > gError = rb_define_class_under(mGLib, "Error", rb_eRuntimeError);
>
> 使っていないとは思いますが、
> glib-2.0ではエラーを一手に扱うGErrorという構造体があるので、
> ひょっとしたらそれをラップする事もあるかなと思って、
> 一応そのまま持ってきました。
んじゃ、いったん削除しましょう。GErrorを実装するときがあれば
そのときにまた考えましょう。
> > rbgobj_object.c:
> > ・/* XXX */のところでcinfoがNULLの時ってあるんですか？
> > 異常系のみの場合は、rb_bug()かなんかの方が良くないですか？
>
> XXXと書いたのは、cinfo->freeを呼ばなくしてしまった事についてでした。
> 何故そうしたかというと、先のメールでは書き忘れてしまいましたが
> GObjectのリファレンスカウンタを実験的に使おうとしていたからです。
>
> ちゃんと呼ぶようにも出来るのですが、cinfo->freeは現在使われていないので、
> 後回しでいっかと思って。(^^;;
えっと、まぁそうなんですが、使わないなら、gobj_mark()もいらなくなりますし
この際、削除した方がスッキリすると思います。
ふと思ったのですが、g_object_ref/unref前後（じゃなくても良いけど）のGObject
ってmalloc/freeって必要ないんですかね....。
> > ・clear_gobject()って使う予定アリですか？
>
> これもgtkからそのまま持ってきました。
> gtkではgobj_destroy()がこの関数を使っているようですが、
> GtkObjectと違ってGObjectにはdestroyが無いのでglibでは不要のはず。
> gtkの方ではどうだろう……
gtkのgobj_destroy()の中でもあえて別関数化する必要は無さそうですねぇ。
当初は何か意図があったのかもしれませんが、これもいったん削除ということで。
> > ・_gobject_to_ruby(), _gobject_from_ruby()って何に使うんですか？
> > （不勉強ですみません）
>
> rbgobj_gvalue_to_rvalue()とrbgobj_rvalue_to_gvalue()による
> VALUE<->GValueの相互自動変換に使われます。
あ、ちょっと説明が悪かったですね。実は、Init_gobject_gobj()内の
rbgobj_register_r2g_func(rbgobj_cGObject, &_gobject_from_ruby);
rbgobj_register_g2r_func(G_TYPE_OBJECT, &_gobject_to_ruby);
の意図がちょっとわからなかったんです。
これって何を意図してるんでしょうか。
> > ・gobj_smethod_added()って何に使うんでしょうか？
>
> シグナルハンドラを特異メソッドとして書くためのもののようです。
具体的にはどのようなコードを意図してるんでしょうか。
win = Gtk::Window.new
win.singleton_method_added(?????)
????
あり？全然イメージできないです....。ごめんなさい、教えてください。
> > ・rbgobj_param_spec_get_struct()とrbgobj_param_spec_wrap()って、
> > Ruby/GTKで言うところのget_xxxxとmake_xxxxですよね....。この辺の
> > 名称ってできればRuby/GTK統一したいですね...。
> > ＃この辺、後述します。
>
> rbgobj_param.cは手をつけてはみたけど、今のコードは捨てたいなぁ。
> GObjectでないGTypeInstanceをうまく扱えるような枠組みを作った上で、
> 書き直したい感じ。
ひとまず、Ruby/GTKなんかに影響しない範囲であれば一度ざっくり削っちゃ
っていただいて構いません。
> > ・rbgobj_class_infoですが、新たに2つのメンバを追加しませんか。
> >
> 扱う対象をGObjectの派生クラスに限定するならば、
> refとunrefはg_object_ref(),g_object_unref()だけでおっけーのはずなので、
> ref,unrefは不要だと思います。
> # gtk_object_ref(), gtk_widget_ref(), etc... はただの糖衣構文。
おぉ。なるほど、気づきませんでした。なら不要ですね。
> > んで、rbgobj_gobject.cのrbgobj_set_gobject()を以下のような感じ。
> > ----------------
> > void
> > rbgobj_set_gobject(obj, gobj)
> > VALUE obj;
> > GObject* gobj;
> > {
> > VALUE data;
> >
> > const rbgobj_class_info* cinfo = rbgobj_lookup_class(rb_class_of(obj));
> >
> > if (cinfo)
> > cinfo->ref(gobj);
>
> リファレンスカウンタについては僕もだいぶ混乱しているのですが、
> 現状だと、各クラスのinitializeの実装はunrefしないので、
> ここでrefしてしまうのはまずそうな気がします。
> # もちろん、unrefするようにinitializeの方を変更すれば良いのですが……
initializeの方でunrefって、unrefしたオブジェクトを使い回すということに
なるので、ちょっと気持ち悪い気がします。
> ストーリィ
>
> 1. initializeメソッド内で、hogehoge_new()を呼び出して、
> 新しく作成されたオブジェクトのリファレンスを得る。
> この時点で、リファレンスカウンタは1
これって、例えば、rbgtkbutton.cのbutton_initialize()とかのことを言ってますか？
どこでリファレンスカウンタが1になるのでしたっけ。ちょっとわからないんですが...。
> 2. set_gobject()する
> ここでrefしてリファレンスカウンタは2になる。
> 新しいリファレンスはrb_cDataのインスタンスが持っている。
>
> 3. initializeからリターン
> ここではunrefしていないので、リファレンスカウンタは2のまま。
>
> 4. Ruby側のラッパがGCされる。
> rb_cDataのインスタンスが持っていたリファレンスがunrefされるので、
> リファレンスカウンタは1
>
> 5. glib側のオブジェクトは解放されない。
えっと、これって今のRuby/GTKの実装がってことでいいでしょうか？
さかいさん的には、2.でrefしなくても良いんじゃないかって解釈で良いでしょうか？
> > rbgobj_value.cのrbgobj_gvalue_to_rvalue()とrbgobj_rvalue_to_gvalue()ですが、
> > これって、結局のところVALUE<->GValueの相互自動変換ですよね？
>
> そうです。
> シグナルハンドラの引数と返り値の変換を個別に書かなくても
> 良いようにするために導入してみました。
>
> > であれば、rbgobj_make_gobject()とかも同様のメソッド名で統一できたらすっきり
> > しそうな気がするのですがいかがでしょう？
> >
> > rbgobj_gvalue2r()
> > rbgobj_r2gvalue()
> > rbgobj_gobj2r() → rbgobj_get_value_from_gobject(),rbgobj_make_gobject()の置き換え
> > rbgobj_r2gobj() →rbgobj_get_gobject()の置き換え
>
> これも賛成。
> 多分、問題ないと思います。
さらに、INT2FIXみたいなマクロを用意するとスッキリするかも。
GOBJ2GVAL()
RVAL2GVAL()
GOBJ2RVAL()
RVAL2GOBJ()
--
.:% Masao Mutoh<mu...@hi...>
|
