[PHP-dev 602] Re: 機能の追加／変更

[Yasuo Ohgaki]

大垣です。

Moriyoshi Koizumi wrote:
>>>いずれにしてもブランチは作らないといけないと思います。
>>>もしよろしければ、今週末あたりにマージ作業を開始します。
>>>ブランチ名は PHP_I18N とかでいいでしょうか。
>>
>>cvs.php.netの方という事でしょうか？
>>そちらの方は、コードがある程度形になってから（コミット
>>できる状態になってから）ブランチを作成した方が良いと思
>>います。
>>sf.jpの新しいフィルタをcvs.php.netへ、と言う事であ
>>ればブランチは必要ないと思います。
> 
> 
> ブランチは本家の方の話です。
> でも、これは今週末すぐに作るという意味ではありません。
> 
> あと、しばらくは cvs.php.net の方を新しい形に近づけつつも、
> それと同時に sf.jp の方でも形にしていくのがよいのではないでしょうか。
> この点では大垣さんのおっしゃることと考えは同じです。

小泉さんがマージされるのでやり易い方法で構わないですが、4.4.0は
当分先ですから、比較的スグにマージするのであればビッグバン方式の
方が面倒も少ない、問題があってもデフォルト無効かつ直す時間は十分
あるので良いと思います。

この手のマージの場合、個人的には、少しずつパッチを見るより大きな
パッチ全体を一度に見れる方が、元のソースとマージ先のソース、マージ
するパッチの違い等を把握し易いので助かります。

# 一時的とは言えsf.jp、cvs.php.net*2 で3つのソースの
# 面倒を見るのは無用な手間がかかる可能性も高いと思います。
# i.e. 他の方が新しいエンコーディングを追加、etcなど
# 私は、2つまでだったら面倒を見きれますが、3つはちょっと...

押しつようとしている訳ではありません。マージ作業される方がやり易
い方法で、作業されれば良いと思います。

> 私がただ単にソースをちゃんと読んでいないのだとしたら申し訳ないのですが、その
> ような実装は見かけたことがありません。これは、同じようなコードが重複している
> のではないか、という懸念です。とくに main/memory_stream のあたりとの機能の競
> 合が気になります。

コードを良く読んでいないので、あまり深く考えていません

# コードと照らし合わせると矛盾するかもしれませんが :)
# 放置すると返信自体を忘れるので、返信しておきます。

私の考え方ではもしコードが重複していてもモジュール化の方がメリットが
大きい様に思えるので別コードで構わないと思っています。
zlib等と同じように、mb_filterも取り扱えば良い、と思っています。
# 言っている事に整合性があるか心配 ^^;

> 
> 
>>>phpchar_t の話といい、なんだか結局ユニコードになりそうな予感がしますが…。
>>
>>phpchar_tの件、失念しています。
>>色々ありますが、mbstringも内部的にはUnicodeなのでUnicodeで
>>良いのではないでしょうか？
> 
> 
> すみません。不明瞭なことを言ってしまいました。
> Unicode といっても、UTF-8 を使ってあくまで 8ビット系統との互換性を持たせるの
> か、UCS-2 なのか、UCS-4 なのかでかなりニュアンスが変わってきますね。
> UCS-2 なら、私はエンジンのユニコード化にはあまり賛成しません。

深く考えていませんが個人的には
UCS-4 に +1
UTF-8, UCS-2 に 0
です。

Andiはzvalのref_countのshortからlongに変えるだけでもメ
モリのコピーが云々と言う意見だったので多分UTF-8派!?

ベンチマークを取って較べた方が無用な議論が無くて済むかも知れ
ません。

--
Yasuo Ohgaki