chise-db

Koichi KAMICHI kamichi @ fonts.jp
2005年 6月 21日 (火) 21:51:44 JST


上地です。

> > > > 1)featureとby_featureの対称性

> system-char-id をなるべく UCS の code point に合わせるという小細工は維
> 持し、system-char-id と =ucs の値が一致すれば =ucs の値を省略する小細
> 工はやめるというのはどうでしょうか?

素晴らしいと思います。

> API ありました。すっかり忘れてました。(^_^;;;
> 
> chise_feature_set_property_value (CHISE_Feature feature,
> chise_feature_load_property_value (CHISE_Feature feature,
> chise_feature_gets_property_value (CHISE_Feature feature,

あ、これでしたか。

> > > ;; 関数 chise_ccs_decode と関数 chise_char_load_feature_value 等で
> > > ;; 継承をサポートするか、別に継承サポート版を作るべきだと思ってい
> > > ;; るのですが、どっちの方針で行くか決心が付いてません。ご意見くだ
> > > ;; さい。

まだ使っていないのでなんともいえないのですが、この継承関係は人の主観で変
化する可能性はありますか?ないのでしたら関数に引数1つ加えて継承の有無を
選択できると便利だと思います。継承をサポートする検索は必要になってくるの
で、あると嬉しいです。

> libchise を一般化した libconcord を作ろうとしているのですが、その際、
> やってしまいます。
> 
> ;; ちなみに、文字素性の継承、文字定義の継承のサポートの問題もあり、
> ;; libchise の API をいじりたいと思っているのですが、その際、既存の 
> ;; API に対する backward compatibility はあった方が良いでしょうか?ま
> ;; たその場合、ABI も同様でしょうか?

私個人としては不要です。まだ固まっていないものだ、と考えていました。

> ;;; 文字列割当関数、文字列参照関数、文字列開放関数、object
> ;;; parser&allocator, object marshaler, object finalize を指定できるよ
> ;;; うにして、アプリケーションのメモリ管理機構や構造データ管理機構と
> ;;; 連係して、構造データを効率良く扱えるようにしたいと考えています。
> 
> ;;; 一応、libchise(ないしは concord)でも default の(標準のという意
> ;;; 味ではない、やる気のない、簡単な)文字列管理機構(といっても、限り
> ;;; なく malloc & free に近いもの)を提供するつもりではありますが。

今のままでも使えるとは思いますが、あるといいなと目先で思っているのは以下
の2点です。

1)entity reference表記 と CCS + コードポイント表記 との変換
2)S式、リスト形式 のデータの解釈

#ids-find(私はどちらかというとfeature-findとして使っていますが)で、関
連オブジェクト同士を昔etoさんから見せていただいたgraphvizで表現するとわ
かりやすいかと考えています。そういう意味で早く手元でids-findに相当するも
のを構築したいのですが、ちょっと足踏み中です。

--
上地宏一 Koichi KAMICHI <kamichi @ fonts.jp>





More information about the CHISE-ja mailing list