「ますさんのパッチをどうか? と思う点について」への返信

elfさんから色々と指摘を頂いた件ですが。一応、ちゃんとした形で返信はしておかないとなぁ。。。と思った次第。

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

関数の使い分けをしなければいけない理由がPHPスクリプトを記述する人間には全くありません．
少なくとも，mb_list_encodings()とmb_list_encodings_alias_names()が分かれて幸せな人はいないと考えます．

少なくとも幸せになれる人がココにいます。：）
というのはさておき、以前の日記にも書いたのですが、全ての値をMIXしてしまうと「どれがエイリアスなのか実体なのか」を判別するのが戻り値を見ただけでは判別できません。分かれていた方が全然幸せですね。
「mb_list_*」関数群はlibmbfl内で定義されている（それぞれの）情報を返します（実体・エイリアス・MIME）。
自分が使いたいケースとしては、圧倒的にmb_list_encodings_alias_names関数の引数有りとmb_list_encodings関数の引数有りが多くて、逆にmb_list_encodings関数の引数無しの情報は必要としていません。

mb_list_encodings()の仕様変更について

mb_list_encodings()が今回のように引数を持ったのはいいことだと思います．
しかし，引数と返り値が変化して都合のいい人はあまりいないと思います．

mb_list_encodings関数はlibmbfl内で定義されているエンコーディングの*実体名称*を返すので問題ないのかと。
元々マニュアルの記載が間違っていて、「サポートされる全エンコーディングを配列で返す」のではなくて「libmbflでサポートしている*実体名称*の全エンコーディングを配列で返す」が正しい表現です（エイリアス名称の一覧は含まれない）。

返値に無駄な値がある

「mb_list_*」関数群はlibmbfl内で定義されている（それぞれの）情報を返しているので、取捨選択（というか個人の勝手な判断）をモジュール内で行なうのは流石にマズいのかと。
たとえ無駄な値があったとしても（個人的に「それ要らないんじゃね？」と判断したとしても）、です。
モジュール内では、そのような判断はしない方がよいと思うのですが。

mb_list_mime_names()が小は大を兼ねない問題

この場合、意味合い的にmb_preferred_mime_name関数と等価なので、丸めれられても問題は無いのかと。

% ./php-4.4.3RC1-cli -v
PHP 4.4.3RC1 (cli) (built: May 28 2006 06:49:21)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies
% ./php-4.4.3RC1-cli -r 'var_dump(mb_preferred_mime_name("base64"));'
string(6) "BASE64"
% ./php-4.4.3RC1-cli -r 'var_dump(mb_preferred_mime_name("SJIS-win"));'
string(9) "Shift_JIS"

できれば、何がどうでアレで現状取れなくて困ってるからああなってくれれば助かる、みたいな具体的な意見を頂ければ嬉しいのですが。その方が（より）実りのある議論ができると思うので。
重箱の隅をつつきあうのは疲れるだけで（その先に）実りがあるとは思えませんので。よろしくお願いします。