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

[Rui Hirokawa]

廣川です。

> 近い未来 PHP-ICU かそれの同等品が PECL に入るでしょう。しかも、今後、
> 新規開発には mbstring の代わりに機能豊富な PHP-ICU が使われるケースが
> 増えるかもしれません。
> 
> PHP の国際化モジュールが mbstring / gettext だけでなくなり、かつ
> あちらの開発者は明らかに mbstring よりも PHP-ICU を好むでしょうから、
> mbstring がデフォルトパッケージのモジュールである正当性がやや
> 薄れてきてしまうと思います。ちょっと不本意なところですが。

この辺，よくわからないところがありますね。mbstringは国内のユーザ
(書籍の出版数などからするとけっこうな数がいる)を中心に，現状でも
多くのユーザーがいます。開発者の好みでデフォルトのパッケージが
決まるというのは，いかがなものかと思います。
マルチバイト圏出身のコアな開発者がほとんどいない現状からすると
いたしかたないかもしれませんが。。。

> 
> そのような流れを作らないようにするためには、
> mbstring の代替としての PHP-ICU というパラダイムではなくて
> 建前としてはユーザがそれらのモジュールを自由に「選択」できる
> んだ ("There are more than one ways to do it?") という状況が
> あればよく、そちらの方が (オープンソースプロジェクトとしては)
> 健全な流れだと思います。

選択枝が複数あたえられてユーザが好む方を選択できるというのは，
たしかに良いことだと思います。

> 
> それを実現するためのインフラ、例えば安定性の高いダイナミックなモジュール
> ローディングであり、pluggable な文字コード変換 API などが
> 整備されれば、そのときは mbstring を意思表示として PECL に
> 移動するときだと思います。

pluggable な文字コード変換 APIというのは，mbfilterなどの変換エンジンを
選べるようになるという意味でしょうか？それとも使用する文字エンコーディン
グごとに変換モジュールを読み込めるようになるという意味でしょうか?

意思表示というのはよくわかりませんが，PHP-ICUと同等の選択枝でありたいと
いう意思ですか？

> 
> > もちろん、他のエクステンションも含めてPHP全体のコードサイズを小さくする
> > ことで、品質管理を容易にする方向性は間違っていないと思います。
> 
> これらは副次的ベネフィットだと思っています。コードサイズのもたらす恩恵と
> いうよりは、本体とは別個のリリーススケジュールを持てるというところに
> ポイントがあるような気がします。

これもありますね。
この点は，PECLの意義としてWez氏も主張されていますね。

> 
> ところで、この議論とは別ですが (私も少し混同しているきらいがありますが)
> libmbfl を mbstring にバンドルするという形を止めて、libmbfl を個別に
> リリースするという話に関してはいかがお考えでしょうか?

将来のことはわかりませんが，現状ではユーザーの便を損ねる結果になると
思いますので，個人的には反対です。
ただし，libxml2等の主要なライブラリのバンドル状況との見合いで，PHP5の開
発方針にそぐわないということであれば，バンドルされなくなるのも致し方ない
とは思います。

この場合，たとえlibmbflがPHPのソースコードのバンドルからはずれても，
Win32のパッケージやRPMなどのパッケージにlibmbflは同梱されることになるで
しょうから，ユーザーの便はさほど変わらないかもしれません。
(これについては，別の意見をお持ちのかたもいるかと思いますが。。。)

> 
> <snip>
> > ICUを中心とした試みにも期待していますが、こちらは勉強不足でよくわかりま
> > せん。数年前にICUのことを調べた際には超巨大なライブラリという感じがしま
> > したが。。。
> 
> PHP-ICU プロジェクトで提供されるのは次のような関数です。

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

-- 
Rui Hirokawa <rui_hirokawa ＠ ybb.ne.jp>