From: Hidetoshi NAGAI Date: 2005-08-07T09:36:28+09:00 Subject: [ruby-dev:26760] Re: TkCheckbutton#variable as getter? 永井＠知能．九工大です． From: H.Yamamoto Subject: [ruby-dev:26757] Re: TkCheckbutton#variable as getter? Date: Sun, 7 Aug 2005 01:22:55 +0900 Message-ID: <20050807012254.73A012A8.ocean@m2.ccsnet.ne.jp> > もしかするとこの拡張の未適用分のためかもしれませんが、treectrl のデモが > エラーを出すようになっていることに気づきました。 いえ，単純に修正ミスによるバグです．ごめんなさい． __item_*_optkeys は item に関する引数を一つ受け取るように 作る必要があるんですが，先のパッチの時点では書き忘れてました． # 互換性のために，tk_trace_variable を呼んでいる部分を # 残す方策をとるべきかは悩ましいところですが． 以下の部分はこのリプライを書き始めた後に訂正されてしまいましたが， 念のために書いておきます． > 第一感、ルートクラスよりはサブクラスで処理すべきことのように感じました。 (snip) > これなら、'variable' などのキー名とマッチングする必要がなくなるので、速度上 > メリットがあるような気がしました。（試してないので裏付けはありません） メソッド定義にしてしまう場合，cget や configinfo で アクセスされた場合に備えて __methodcall_optkeys に 定義を加えなければなりません． # でなければ widget.opt はできても widget[opt] が動かなくなる． __methodcall_optkeys のチェックは高い優先順位で通りますから， 残念ながら比較回数を減らすことにはならないと思います． さらにその場合，configure(hash) で複数オプションに対する指定を 与えた場合や new(hash) での指定についても，個別オプションごとに tcl 側を繰り返し呼び出すことになります． tcl 呼び出しはコストが大きいので，その回数はできるだけ押さえた方が 速度面でも有利ではないかと考えますが，いかがでしょう？ ただし，textvariable はともかく variable をトップレベル定義から 外すのはありかと思います． textvariable は options のマニュアルに含まれていることから 一般規則として扱っても良いでしょうけれど，variable は 含まれていませんので． それでも variable を加えてもいいのではないかと思うのは， textvariable と同程度には一般的に成り立つだろうと見たためです． つまり，もし新しい Tcl/Tk or その拡張で variable という オプションが追加された場合，それを変数を指定するオプションと 考えても差し支えなく，それゆえ Ruby/Tk を新しくすることなく 自動的に対応できるだろうという話です． -- 永井 秀利 （九工大 知能情報） nagai@ai.kyutech.ac.jp