[PHP-dev 1040] Re: Fwd: [PHP-I18N] Re: ICU Extensions for PHP

[Moriyoshi Koizumi]

小泉です。

お返事遅くなってしまいました。

On 2004/11/07, at 14:18, Rui Hirokawa wrote:

>> それを実現するためのインフラ、例えば安定性の高いダイナミックなモジュール
>> ローディングであり、pluggable な文字コード変換 API などが
>> 整備されれば、そのときは mbstring を意思表示として PECL に
>> 移動するときだと思います。
>
> pluggable な文字コード変換 APIというのは，mbfilterなどの変換エンジンを
> 選べるようになるという意味でしょうか？それとも使用する文字エンコーディン
> グごとに変換モジュールを読み込めるようになるという意味でしょうか?
>
> 意思表示というのはよくわかりませんが，PHP-ICUと同等の選択枝でありたいと
> いう意思ですか？

分かりにくい記述ですみません。ここでの意思表示というのは、mbstring に関し
「大勢に使われており、デフォルトで有効であるべきモジュール」という主張を
繰り返してきた私たち自身の手で PECL に移動することで、PHP-ICU とも
同等の選択肢だということを強調し、また、PHP-ICU によって置き換えられる
ものでもないということを示すという意味合いです。

>> ところで、この議論とは別ですが (私も少し混同しているきらいがありますが)
>> libmbfl を mbstring にバンドルするという形を止めて、libmbfl を個別に
>> リリースするという話に関してはいかがお考えでしょうか?
>
> 将来のことはわかりませんが，現状ではユーザーの便を損ねる結果になると
> 思いますので，個人的には反対です。
> ただし，libxml2等の主要なライブラリのバンドル状況との見合いで，PHP5の開
> 発方針にそぐわないということであれば，バンドルされなくなるのも致し方ない
> とは思います。

「ライブラリをバンドルできる要件」というものは、現状を鑑みても
かなり恣意的なものに感じられますね。
そういう意味では mbfilter のバンドルが方針にそぐわないということは
ないと思いますが。。。

# 私には単に PHP にライブラリをバンドルするのを避け、
# パッケージを lean and mean にしたいという気持ちもありますが。

> 解説ありがとうございます。機能は豊富な気がしますが，
> これがユーザに受け入れられるには，わかりやすい形で
> 提供される必要があります。
> 現状の実装は，私には複雑で分かりにくいものに見えます。
> (知識があまりないせいかもしれませんが。)

要は良質なドキュメント次第ということでしょうかね…。