YamaKen
yamak****@bp*****
2005年 1月 8日 (土) 03:15:43 JST
At Sat, 8 Jan 2005 01:27:01 +0900, tkng****@xem***** wrote: > > On Fri, 07 Jan 2005 09:11:01 +0900 > YamaKen <yamak****@bp*****> wrote: > > uim_custom_quit()の後にもう1回uim_quit()が呼ばれますよね? 本来は > > その時点でカウントが0になるべきなのでuim_init()かuim_quit()が過 > > 剰に呼ばれてるバグがあるんじゃないでしょうか。もっとも以前の仕様 > > ではuim_init()を過剰に呼んでもバグとは言えませんが。 > > uim_quitを2度呼ぶバグがありました。これを修正するとこの方法でも動きま > した。ただ、それとは別に、私はuim_init/quitとuim_custom_init/quitをわけ > るのはデザインとして好きではないので、 [Anthy-dev 1563] 式のAPIを引き続 > き提案します。 参照カウントの話とは独立に、uim_quit()を2度呼ぶバグの方は修正 commitお願いします。 > > At Fri, 7 Jan 2005 07:36:56 +0900, > > tkng****@xem***** wrote: > > > というわけで、このデザインだとうまくいきません。そこで、次のような > > > 解決策を提案します。 > > > > > > - uim_custom_init/quitはuim_init/quitのなかに埋め込む。 > > > - フル機能を必要とする場合にはuim_custom_enableとか、そんな感じの > > > 関数を明示的に呼ばせる。 > > > > > > これでリソースの問題も解決できると思うのですがどうでしょう？ > > > > uim-prefのようにimmoduleも読み込まれる環境ではuim_init()が呼ばれ > > る前にuim_custom_enable()を呼ぶのは難しいと思います。また、 > > uim-customのコードはlibuimのコアから簡単に外せるように独立性を保っ > > ておきたいので、できれば今のインタフェイスを維持したいです。そん > > な面倒なと思うでしょうが、libuimはまだまだスリム化したいと思って > > います。その一環と考えてください。 > > いえ、uim_custom_enableが呼ばれるのはuim_initの後です。つまり、今 > uim_custom_init内でやっている処理をuim_custom_enableで行うと。 そういう意図でしたか。賛成しますが、行き違いがあるとまずいので再 確認させてください。くどいですが。 > > > - uim_custom_init/quitはuim_init/quitのなかに埋め込む。 ・これは間違いで、uim_custom_init()はuim_init()の中に埋め込まない ・uim_custom_quit()はuim_quit()の中に埋め込む という主張で合ってるでしょうか。 さらに、 ・uim_custom_enable()の実態は現在の実装でuim_custom_init()がやっ ている処理そのまま。名前が変わるだけ ・uim_init()は今までの仕様通り何回呼んでも構わない。参照カウント によるuim_quit()との対応は行わない という事でいいですか? これでよければそのように実装しておきます。 本来はlibuimコアの側からuim-customに干渉するのは避けたいところで すが、現状ではuim_custom_load()等の呼び出しも必須になってしまっ ているので、API利用者の負担を増してまで無理に分離させる価値は無 いと判断しました。enableという概念もinit/quitと問題なく共存可能 だと思います。 将来的にはpluginとして実装してload/unloadをもってinit/quitに代え るのがベストかなと思っています。この場合はuim_quit()時にも汎用の 仕組みで暗黙的にunloadできるわけですし。 ------------------------------- ヤマケン yamak****@bp*****
