libchise化の問題
Kouichirou Eto
ml2004 @ eto.com
2004年 7月 7日 (水) 16:13:53 JST
江渡です。
Ruby/CHISEのlibchise化をすすめているのですが、その過程で気付いたことを
メモしておきます。
Ruby/CHISEでは様々に高度な機能を実現するために、どうしてもlibchiseだけ
では機能が足りず、その部分をRubyによるハイブリッド化でおぎなっています。
具体的にはまず、libchiseと同等な動作をするPureRuby版(Ruby/BDBを使用)の
libchise_rを作り、追加機能はここに実装しました。その上でC言語による
extension、libchise_cを作り、両者を中間層で統合するという戦略を取って
います。libchise_cを使用している場合でも、必要な機能が無かった場合は
libchise_rにfallbackすることによって、全ての機能が動作するようになって
ます。libchise_rだけでも完全に動作します。
これでなんとか動くようになったのですが、この戦略は大変面倒であり、かつ
メンテにコストがかかりそうです。かといって、libchiseに機能を全て追加し
てしまうのがいいのかどうか、よくわかりません。さてどうするべきだろうか、
というのがこのメールの主旨です。
具体的に追加した機能を並べてみます。まず、each_ccs_name、使用可能なCCS
の一覧がない。これはeach_feature_nameの逆写像なので本来は
each_feature_nameを用いて実現可能なはずですが…。
CCSに対するeachがない。例えばJIS X 0208集合に含まれる全文字といった
検索をする場合があり、そのために使いました。
IDSから文字を検索するためにcharacter/by_idsという新しいdirectoryを作り
ました。定義からするとby_featureでもいいような気がしますが、実際には
code_pointからchar_idへのmappingだけに限っているため、文字列から
char_idへの対応をするdbは別のtreeにしたほうがいいだろうと判断しました。
(by_idsでの検索が出来るのなら、by_nameによる検索などが出来ても良さそう
な気もしてくるが…。)
libchiseからは外れるかもしれませんが、やはりメタ文字DBが欲しいです。現
在はCCS間の継承関係はアドホックにライブラリに埋め込んでますが、本来は
そのような情報は外に出したい。chise-db/characterと並列に、ccsという
directoryを作り、そこに置くのでどうでしょうか。前回この話が出たときは、
データ構造をどうするかの話でストップしたのでしたっけ。
また上地さんからも話がありましたが、やはりchise-dbが独立して配付されて
いるとうれしい。BDBファイルで配付するという案もありますが、バイナリの
互換性は無いのですよね。データ構造をどうするかは悩み所ですが、当面はS
式のままになるのかなと。
More information about the CHISE-ja
mailing list