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

Moriyoshi Koizumi php-dev@php.gr.jp
Fri, 29 Nov 2002 04:04:53 +0900


小泉です。

> > ご提案有難うございます。標準的なAPIはやはり必要ですね。
> > 
> > まだ、よく見れていませんが、少しだけ意見を。
> > php_mb_*という名前ですが、この辺は、ext/standardまたは
> > main にというイメージでしょうか?
> > Zendエンジンだとzend_mb_* という感じになるかもしれません。
> 
> 4.x系ではext/mbstringに入れる、
> 5.x(または6.x?)系ではZendに入れるという事になるでしょ
> うか?
> 
> main/にいれるのも良いですが、個人的には、どうせならいき
> なりZendに入れてしまう方が良いような気がします。

入れられればそれはその方がいいのですが…。
mbstring が何をするものと ZE の開発者に捉えられるかによる
と思います。ただのマルチバイト文字列処理を行う関数群だったら
エンジンではなく standard に入れるべきだと思われるかもしれません。
個人的には、zend-multibyte 如何かもしれないと思っています。

> APIを考えるのが大変になるので、必ずしも必要とは思いません
> が、php_mb_* APIはzend_mb_* にプレフィックスだけ変更
> すれば良いようにになっているとありがたいです。

この問題はマクロを後で用意すれば解決できそうですが、どうでしょう?

> > On Tue, 26 Nov 2002 11:57:03 +0900
> > Moriyoshi Koizumi <moriyoshi@at.wakwak.com> wrote:
> >>大きな変更点は、スレッドローカルな構造体(tsrm resource)に
> >>エラー番号を格納するのを止めた点です。
> >>コードの可読性を上げる一方で、デバッグがしづらくすると判断したためです。
> 
> もちろん考えられているとは思いますが、マルチスレッドサーバー
> でもエラー番号が正しく設定されるのであればそれでも良いと思
> います。
> 
> # PHPをマルチスレッドサーバーで使うのは恐過ぎて
> # 私はできませんが...

gdb でエラーを追っていくときに、バグトラッキングがしやすいという理由です。
TLS に入っていると、ポインタのポインタをいちいち参照していかなければ
ならないので面倒くさいと思います。

> >>あとは、エラー報告用の関数ポインタ(php_mb_err_report_func)を設けようとして
> >>います。(いま書き途中で中途半端になってしまっています)
> >>前述したように、いつでも php_error_docref を呼べるわけではないので、
> >>場合に応じてエラーの出力方法を変えられるようにこのような設計にしました。
> >>
> >>これに関しては、現在本家の方で、エラーのローカライズについて議論が白熱して
> >>いますので、そちらを参照しつつ意見いただければと思います。
>
> エラーメッセージのローカライズの件と思います。
> 私の意見は大方、Saschaさんと同じです。

ちょっと誤解を招く書き方をしてしまった私が悪いのですが、
このポインタの話は、ローカライズの件とは直接関係ありません。
たまたまかぶっていたというだけです。

関数オーバーローディングの際に php_error を使っていたことで
segfault してしまったように、エンジンが完全に初期化される前に
標準のエラー報告関数を使うことはできないと考えた方が無難ですし、
また、その他エラーメッセージを遅延表示したいこともあり得ますから、
関数ポインタという所に行き着いたということです。
> 
> # PHPマニュアルのコメントを言語毎にノートのDBが変わると
> # 面白いですね。

これは私も思います。が、本家でやらずとも、php.gr.jp でやればいいのでは?
どうでしょう?