[PHP-dev 1037] Re: Fwd: [PHP-I18N] Re: ICU Extensions for PHP
Moriyoshi Koizumi
moriyoshi @ at.wakwak.com
2004年 11月 7日 (日) 08:27:28 JST
小泉です。
On 2004/11/06, at 19:17, Rui Hirokawa wrote:
> 廣川です。
>
> Derickさんとの議論に対応できずすみませんでした。
気になさらないで下さい。そもそも Derick さんが私宛の私信ではなく、
メーリングリストの方で議論を始めれば良かったというだけですから。
> PHP5では環境によらずiconvが使用できる環境になっているという
> 状況を見るとPHP4の頃から少し状況が変わってきているとは感じています。
>
> ただ、私は現時点ではmbstringにPECLに移動するという必然性は感じませんし、
> ユーザにもメリットはないと思います。(アーカイブが小さくなることくらい?)
廣川さんが話に参加して下さったので、言葉足らずだった理屈を
説明したいと思います。
近い未来 PHP-ICU かそれの同等品が PECL に入るでしょう。しかも、今後、
新規開発には mbstring の代わりに機能豊富な PHP-ICU が使われるケースが
増えるかもしれません。
PHP の国際化モジュールが mbstring / gettext だけでなくなり、かつ
あちらの開発者は明らかに mbstring よりも PHP-ICU を好むでしょうから、
mbstring がデフォルトパッケージのモジュールである正当性がやや
薄れてきてしまうと思います。ちょっと不本意なところですが。
そのような流れを作らないようにするためには、
mbstring の代替としての PHP-ICU というパラダイムではなくて
建前としてはユーザがそれらのモジュールを自由に「選択」できる
んだ ("There are more than one ways to do it?") という状況が
あればよく、そちらの方が (オープンソースプロジェクトとしては)
健全な流れだと思います。
それを実現するためのインフラ、例えば安定性の高いダイナミックなモジュール
ローディングであり、pluggable な文字コード変換 API などが
整備されれば、そのときは mbstring を意思表示として PECL に
移動するときだと思います。
# 逆に言うと、そのようなインフラが整わない限り PECL に移動する必然性は
# ありません ^^;
> もちろん、他のエクステンションも含めてPHP全体のコードサイズを小さくする
> ことで、品質管理を容易にする方向性は間違っていないと思います。
これらは副次的ベネフィットだと思っています。コードサイズのもたらす恩恵と
いうよりは、本体とは別個のリリーススケジュールを持てるというところに
ポイントがあるような気がします。
ところで、この議論とは別ですが (私も少し混同しているきらいがありますが)
libmbfl を mbstring にバンドルするという形を止めて、libmbfl を個別に
リリースするという話に関してはいかがお考えでしょうか?
<snip>
> ICUを中心とした試みにも期待していますが、こちらは勉強不足でよくわかりま
> せん。数年前にICUのことを調べた際には超巨大なライブラリという感じがしま
> したが。。。
PHP-ICU プロジェクトで提供されるのは次のような関数です。
http://www.voltex.jp/projects/php-i18n/
- 文字コード変換 (mb_convert_encoding を代替可能)
- UTF-16 文字列操作 (mb 系文字列操作関数 を代替可能)
- リソースバンドル (gettext を代替可能)
- ロカール固有の日付・時間処理 (夏時間、イスラム暦とか)
- メッセージフォーマット (Java のアレ風 [1] + Unicode 対応 printf)
PHP-ICU でやろうとしていることは、私から見るとだいぶ狂気じみた
ことだと思うのですが、どういうことかというと、
1. C++ で記述された膨大なオブジェクト / メソッドを
構造体 + C 関数に置き換える
2. それらの C 関数を PHP の peer でラップする
何故 C++ コンパイラを使って peer で C++ メソッド呼び出しを
ラップしないのか非常に不思議です。
[1] http://java.sun.com/j2se/1.4.2/docs/api/java/text/MessageFormat.html
PHP-dev メーリングリストの案内