[PHP-dev 580] メザコヴロミネミュゴザプヴオキクンヴメザコヴニペゴコヴメザコヴロミネミュトナヨンヴデグボパベゾドズヴギドゴヴエョウョー

[php-dev@php.gr.jp]

大垣です。

mail()がコンパイルされない場合がある事は、前から非常に気になっていました。
個人的にはこれはバグと思っています。

# 私のようにsendmailバイナリはインストールせずにqmail-inject
# かnullmailer-injectを使っている方も多いはずです :)

Moriyoshi Koizumi wrote:
> もちろんその通りなんです。エンジンに入れられるならその方がいいんですが、
> 状況的に反対必至だろう、というのがあります。第一 ZendEngine 1 でさえまだバ
> グがありますし、これ以上使わない機能のことで悩まされたくないと言われそうで
> すから。
> 
> 
>>まぁ仮にそうだとしても
>>
>>- どの辺までエンジンで提供するのか(substrは入れるのかいれないのか、等)
>>- zend_utility_functionsで登録するのか、エンジン自体にmbstring同等の機能
>>  を取り込むのか
> 
> 
> 上の話はまさに zend_utility_functions を意識しています。将来そっちにもって
> これたらいいな、とは思っています。

Zendを言語エンジンとして捉えるなら、基本データ型の情報を取得する関数は
エンジンレベルで実装という考え方は納得できる考え方と思います。

# どこまでエンジンレベルで対応するか、ガイドラインは必要ですが...
# strlen()は個人的にはOkと思います。

>>等々議論の余地はありまくるわけなので、4.3.0が出たら(出る前でもいいですが)
>>大雑把にでもどう進めていくかについて議論したほうがよさそうですね。ここで
>>もいいですし、ircでも、大垣さんが東京方面に来られるついでがあるのでした
>>らオフラインでも良いですし。
> 
> 
> そうですね、私はとりあえず議論はメーリングリスト上で進めたほうがよいかと思
> います。あと、できれば本家の dev の方で。

折角作ってもリジェクトではやり切れないのでこのMLで多少揉んだあと、
本家php-devで提案という方が良いと思います。

# 心配なのはコード全体を理解せずに反対する方がいる事です。
# その上、ちょっと考えれば大問題である事が明白なパッチを平気で
# コミット&放置したり...
# 馬に念仏のような気がするので、自分が困らないものは放置する事
# にしまた :)

それとも、メインの開発環境をsf.netにし、出来上がって安定してから、
「どう？」という方法の方が受け入れやすいかもしれません？！

自分は固定のシングルバイト文字しか使わない=>マルチバイト処理コードは無駄
=>コードも見ないで反対、といった流れが見えるので、アイデアだけでは不毛な
議論になる可能性も高いですね。

> 
> 
>>># sf.jp のものは、4.3.0 リリース後に早い段階でブランチを作って、少しづつ
>>># マージしていったほうがいいと思います。
>>
>>ですね。この辺は次が4.4なのか5なのかにも拠りそうかな、とも思いますが。

php.netとsf.netのソースか乖離してしまったのは私が原因です。
php.netのソースにほとんど追加はない、というつもりだったので
パッチを確認してポートする時間がありませんでした...申し訳ないです。

前向きに捉えて、エンジンとの統合も含めて、mbstringの仕様を大胆に変える
には好都合と思う事にしました。

php.netとsf.netのコードを同期して、そこから再スタートという事で良い
のではないでしょうか。

だた、Andiはずいぶん前にZendEngine2への大幅な機能追加はしたくないと
メールで書いていたのでmbstringの機能をZendEngine2にマージするのは難
しいと思います。

# ZendEngine3(?)で奇麗にまとめるという線が現実的なように思えます。
# 先が長いですね...

>>
>>
>>>そして、その第一段階として、iconv を使って、substr, strpos, strrpos, 
>>>substr_count の等価関数を書いてみました。もしご興味ありましたら、私個人当て
>>>にメールをください。パッチをお送りします。もしくは適当な場所にアップロードし
>>>ます。
>>
>>せっかくなので皆様が見えるところに置くのがよろしいかと思うのですが。僕も
>>見てみたいですし。
> 
> 
> ありがとうございます。とりあえず、
> 
> http://www.voltex.jp/patches/iconv_functions.patch.diff.txt をご覧下さいませ。
> 
> iconv_substr_count() と mb_substr_count() を比較してみれば分かりますが、
> 私の実装がひどすぎるというのもあるんですが、iconv_substr_count() の方が100
> 倍くらい遅いです。
> それでは、ご意見お待ちしております。

コードをまだ見ていませんが、iconv自体が遅いという事もあり得ると思います。

もしかして、私のLinuxのglibc 2.2.4が悪いのかもしれませんが、
pg_escape_bytea()のパフォーマンスが最悪でした。原因はlibpqが使っている
sscanf()で、かなり場当たり的なパッチをpgsqlモジュールに当てておきました。

# 場当たりパッチですがO(n^2)からO(n)になったのでかなり改善しました。
# パッチがない場合、Large Objectを使う場合に較べて100倍くらい遅いケー
# スなど当たり前でした。sscanfを使うと、どうしても遅くなるようなので、
# 時間ができたら関数を書こうかなと思っています。

--
Yasuo Ohgaki