[PHP-dev 657] Re: RFC: 新 API草案

[Moriyoshi Koizumi]

小泉です。

> APIの内容に関しては、特に問題ないと思います。がしがしマージ作業していた
> だいてよろしいのではないでしょうか？

API の利用法に関しての若干の補足ですが、
たとえば、これまでは

php_mb_enc *encoding = php_mb_get_enc_by_name("Shift_JIS" TSRMLS_CC);

if (encoding == NULL) {
    /* エラー処理 */
}

と書けばよかったのですけれども、拙案ですと、

php_mb_enc *encoding;
php_mb_err_t err;

err = php_mb_get_enc_by_name(&encoding, "Shift_JIS", MBSTRG(err_rep_func));

if (err != PHP_MB_SUCCESS) {
    /* エラー処理 */
}

このように多少まどろっこしい手続きが必要になります。

おそらく、この点に関して何らかのご指摘をいただくのではと考えていました。


> で、PHP側かZend側のどちらに入れるかという話ですが、とりあえずPHP側
> (standardでもmbstringでも)で実装して、必要そうなAPIだけzufで登録、という
> ことで良いかな、と思っています(とりあえず、ですが)。
> 
> どのみち全てのAPIをエンジンから提供する、というのは有りえないオプション
> だと思うので、上記のように進めて良い感じなら(mbstringのさらにコアな部分
> を)徐々にエンジン側に機能統合、というのが落としどころかな、と(ちょっと弱
> 気かな？)。

このあたり、まったく同感です。

> エンジン自体のi18nについては...flex使っている限り限界があるといえばある
> のですが、なんとか頑張りましょう:) こちらに関してはもうちょっと考えて見
> ます。

スキャナーだけ flex 使わないという選択肢もありなら少し気が楽になりそうですね。

とにかく、本気で国際化を謳うなら、Shift_JIS や EUC-JP 以外のマルチバイトも
考慮に入れる必要がありますね。たとえば 2バイト目に "\\" が含まれる符号化方式
としては、 GBK(CP936) などがありますから。