MyMiniCity踏んでください!!

ただいま絶賛MyMiniCity参加中です.是非リンクを踏んでください!!(笑
September 21st, 2006

これがオープンソースのやり方

(Read: 2750)
Add to Hatena Bookmark

参照:
実装したもんがすべてで,議論するふりして議論する必要ないんですよ.という世界もある.
ますさんのパッチをどうか? と思う点について - よくきたblog
『「ますさんのパッチをどうか? と思う点について」への返信』への返信 - よくきたblog

の関連ですが,おおよそ結論がでたみたいです.

とりあえず,ます’s Diary - どうでもいい事100選によると,
elfさんから色々と指摘を頂いた件ですが。一応、ちゃんとした形で返信はしておかないとなぁ。。。と思った次第。

関数が追加されることについて

関数の使い分けをしなければいけない理由がPHPスクリプトを記述する人間には全くありません.

少なくとも,mb_list_encodings()とmb_list_encodings_alias_names()が分かれて幸せな人はいないと考えます.


少なくとも幸せになれる人がココにいます。:)

というのはさておき、以前の日記にも書いたのですが、全ての値をMIXしてしまうと「どれがエイリアスなのか実体なのか」を判別するのが戻り値を見ただけでは判別できません。分かれていた方が全然幸せですね。
(snip)
できれば、何がどうでアレで現状取れなくて困ってるからああなってくれれば助かる、みたいな具体的な意見を頂ければ嬉しいのですが。その方が(より)実りのある議論ができると思うので。

重箱の隅をつつきあうのは疲れるだけで(その先に)実りがあるとは思えませんので。よろしくお願いします。


とかありますが,一応実例を挙げ,逆に何故「わかれてないと困るのか,なぜわかれていないよりわかれている方が幸せなのか?」という質問を返してそこで止まっていたのですが,結局下記のようなことらしいです.
[PHP-dev 1330] Re: [PHP-doc 649] mbstring の新関数のマニュアルについて
次に、mb_list_encodings関数のエンコーディング・リスト一覧取得には
全く興味が無くて、

mb_list_encodings関数の引数有りの機能(エイリアスを実体に丸める)
mb_list_encodings_alias_names関数

にしか興味がありません。

なので、mb_list_encodings関数でエンコーディング・リスト一覧を何処
まで返すべきか?という事には、実は、まーーーったく興味がありません。

そもそも、そういう機能を利用していないので、mb_list_encodings関数の
エンコーディング・リスト一覧の結果がどうなるべきか、という事には
興味が薄いです。


あなたが困るというから議論をしようとしたんですよ.使ってないんじゃないですか.
説明しろといいつつ議論をする気がなかった.結局3ヶ月放置で最終的に追求するとこれです.ようするに「最初から話する気ないべ.うまいこといっときゃOK」ですか.
これがPHPクオリティなんでしょうか?
議論する気がないならないと最初から言えばいいのに.

更に、別関数にしたのは、UNIX的では無い、という考え方の他に、あさかわ
さんが指摘しているように、当初の設計者を尊重、したのもそうですが、
改修した事になって起こりえる影響範囲が想像できなかった、という事も
あります。

中途半端に実装して、変なリスクは負いたくないし、実体エンコーディング
しか返さない仕様は、何かの意味があったんだろう、と思っているので。


だから実装した人間に聞いてみれば? って意味で php-dev@ を提案しているわけで.
多分廣川さんか小泉さんだと踏んでいたので(苦笑 php-dev@php.gr.jp を提案したわけですが,
別にphp.gr.jpじゃなくphp.netでもいいんですけど.
上記「実装理由が不明」ということなら私が誰がどういうつもりで実装したのかがんばって調査しましたよ.
また,急いで実装する必要はあったのでしょうか? 今までの歴史的にほとんどの人にとって「あると便利」だけど「無いと困る」というレベルの物ではないと思います.
それともこれがないとあなたが困るからコミットしたんですか?

最後にですが、mb_list_encodings関数で全てのエンコーディングを返す
ようになった場合、現時点では、そこからエイリアスになっている情報を
取り除く事がシステマッチックには出来ません。

更に言うと、どのエイリアス・エンコーディングが、どの実体エンコーディング
と対になっているのかでさえ、システマッチックには分かりません。

それに対応する為に、mb_list_encodings関数の引数を増やしたりする等して
機能を拡張していく事になると思いますが、どんどん柔軟性に欠如していき、
最終的には自分自身の重さで身動きが取れなくなってしまう事が想像できます。
流石に、それは阻止したいんですけど。
(snip)現状、mb_list_encodings関数の(実体エンコーディングの一覧を返す)
仕様は全く変更していないので、別に、現状から更に悪くなる、という訳
ではありません。良くも悪くも、変わらず。


とかいいつつmb_list_encodings()に引数を追加したのは誰でしょうか?
つまり既に改変を行っており,現状維持はされていないわけです.あなたのメッセージとは相反する行動をあなた自身がしています.
一応書いておきますがこのメールを書いたあなたですよー.忘れないでくださいね.


さて本当にmb_list_encoding_alias_names()とかいうの対応したi18n化を考えないといけないのかー

※2006-09-22補足
ちなみに

現状の仕様はともかく、まず第一に一つの関数内で色々やらせようとする
事は、最近読んだ文書から引用させて頂きますと、UNIX的では無い、と
いう事です。

http://d.hatena.ne.jp/asin/4274064069

一つの事を上手くやらせる、という行為から徐々に脱線している感じが
しています。


とありますが,php.netで開発しているのはUNIXではありません.(少なくともこの件は)PHPです.
例えばsendmailのラッパー関数はmail()です.しかしこれはビルド環境(OSが何か,sendmailは見つかったかなど)によって柔軟に動作が変わります.
mbstringでも,「マルチバイトメールメッセージを作る関数」ではなく,「マルチバイトメールを送信する関数」が実装されています.
これは完全に何らかのlibmbfのラッパーではありません.
その他同様に「単にラッパー」ではなく,「簡潔にスクリプトを書けるように実装する」という部分がPHPには多く存在します.

#当然単にラッパーの物も多く存在します

UNIXもファイルIOにはopen・closeだけではなく,fopen・fcloseなどもあります.
つまり,何でもかんでもラッパーにすればいいわけではありません.
残念ならが件の書籍は読んでいないので.的確の要点を理解できていないかもしれませんが,
少なくとも,UNIX的文化というものを既存メンテナーの方や実際のユーザーの人との議論なく,独自の判断で不必要にごり押しする判断基準にするには弱いのではないのでしょうか?
PHPはあなただけが作り,あなただけが使っているわけではありません.
当然私だけがつくり,私だけが使っているわけではありません.だからMLでとオンラインでも口頭でもできる限り丁寧に提案していたわけです.
すべてが無駄だったようで残念です.

トピックの参照元

▼最近のトピック

▼ 人気のトピック


< 過去の記事 [ 9All Categories ] 新しい記事 >
Powered by gsblog (customize)

[ POST ] [ AddLink ] [ CtlPanel ]

Subscribe blog

Bookmark blog

About me

about me

応援しています

我が息子が産まれたアクア・バースハウス(東京都世田谷区にある助産院)を応援しています.

翻訳のお仕事

腕に自信がある方,修行をしたい方はこちらをどうぞ.

2006 calendar

9月
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
| Day | Month | Year |

Powered by RRDTOOL.

Archives

Categories

Links


Mail to admin

人気ブログランキングへ RSS feed meter for http://blog.poyo.jp/ Search Engine Optimization
blogpeople.netに登録!! スカウター : よくきたblog

My Google news

My Google News

Related site

ころんころん♪ べびぽよ フォト蔵Wiki
string(40) "/categ-1/year-2006/month-9/id-1158769458"