(jp) =
PHP 8 用の新しい RFC があり、その名前は名前付き引数 RFC です。
投票する資格がある場合、または投票できる人を知っている場合: 5 分間でこれを読み、前もって明確にするようお願いしたい: 賛成票を投じてほしい.
これが、ユーザーランド開発者の観点から見た理由です。両方ともクライアント プロジェクトの場合です。 と オープンソース。
# OSSメンテナーとして
名前付き引数に対する主な反論 — PHP 8 の駄洒落は続きます — は、オープン ソース ソフトウェアの維持が苦痛になるというものです。引数の名前を変更すると、重大な変更になります。
これが意味するところです。 パブリック API の一部としてこの機能を持つオープン ソース パッケージを想像してみてください。
public function toMediaCollection(string $collection, string $disk = null);名前付きパラメーターを使用すると、次のようにこの関数を呼び出すことができます。
$pendingMedia
->toMediaCollection(collection: 'downloads', disk: 's3');なんらかの理由で、オープンソースのメンテナが名前を変更したい場合 $collection また $disk 名前付き引数は重大な変更を行うため、メジャー リリースにタグを付ける必要があります。
さて、オープンソースのメンテナーとしての私の観点から、あなたに何か言わせてください。これはめったに起こりません。
実際のところ、ほんの一握りの出来事しか思い浮かびません。 そして、これらの発生で名前を変更することにした唯一の理由は、すでに新しいメジャー バージョンに取り組んでいて、その過程でネーミングを少し改善する必要があると考えたからです。
ところで、その意見を持っているのは私だけではありません。Nicolas Grekas は賛成票を投じた人々の 1 人であり、OSS 開発についてある程度知っています。 あ、これは モハメド・サイード、Laravelのコアメンテナの1人:
私は Laravel で 4 年間働いていますが、リファクタリングで引数名を変更したいと思うことはめったにありません。 引数を追加または削除しますが、名前を変更する必要はありませんでした。
実際、それは興味深い考えです: 引数リストはすでに それは 後方互換性を損なう傾向があります: 引数の順序を変更することは、すでに重大な変更です! そして、私たちは今それをうまく扱っていますよね？
今でも もしも オープンソースのメンテナーとして、引数名がメジャー リリース間で変更されないようにする責任を負いたくない場合は、次のようにします: 名前付き引数を積極的にサポートしないことをユーザーに伝え、それらを使用することは自己責任で。 これをREADMEに入れるだけです：
**Heads up**: this package doesn't actively support named arguments.
This means that argument names might change in minor and patch releases.
You can use them, but at your own risk.すべての PHP 開発者にこの柔軟性を否定しないでください。遠い将来、どこかで何かが壊れる可能性がわずかにあるのではないかと心配しているからです。 恐れるな。
# クライアントの仕事をするプログラマーとして
もう 1 つの議論は、この RFC が不適切な API 設計を助長するというものです。 それは人々に大規模なメソッド定義を書くことを奨励し、それはしばしばコードのにおいを示します.
私も、名前付きパラメーターに適していない多くの例を思い付くことができます。 しかし、それはそれらのユースケースがまったくないという意味ではありません! データ転送オブジェクトまたは値オブジェクトについて聞いたことがありますか? このブログをフォローしている場合は、可能性があります。
この投稿でそれらに関する私の文章をコピーするつもりはありませんが、それらの背後にある主な考えを要約することはできます: データをアプリケーションの第一級市民として扱い、オブジェクトでモデル化します。 たとえば、住所には番地、番地、郵便番号、都市、国、場合によってはそれ以上のものがあります。 そのデータは、PHP で厳密に型指定されたオブジェクトによって表され、コンテキスト間でランダムなものでいっぱいの配列として渡されないようにする必要があります。そのコンストラクターは次のようになります。
class Address
public function __construct(
string $street,
string $number,
string $postal,
string $city,
string $country,
)
DTO と VO は、これらの種類の大規模なコンストラクターが許可されている有効なケースであり、コードの匂いはまったくありません。 私たちの古いプロジェクトをざっと見たところ、その統計を追跡した時点で、すでに 63 の DTO クラスがあり、プロジェクトはその時点ではまだ完成していませんでした!
大規模なコンストラクターが発生し、名前付きパラメーターはより明確になるだけでなく、順序を修正することをまったく心配することなく、事後にパラメーターの順序を変更する柔軟性を提供します。
私たちの Address たとえば、オブジェクト。 数字のサフィックスをサポートする必要があるとしましょう。 他の場所で呼び出された順序を気にすることなく、その引数を追加できます。
class Address
public function __construct(
string $street,
string $number,
string $numberSuffix,
string $postal,
string $city,
string $country,
)
確かに、呼び出し元サイトはそれを追加する必要がありますが、少なくともパラメーターの順序を細かく管理することについて心配する必要はありません。
しかし、ユーザーが代わりに順序付けられた引数を使用することを決定した場合はどうなるでしょうか? これらの場合、名前付き引数が確実に使用されるようにする何らかの方法が必要です。 答えは驚くほど退屈です。チームで規則を確立し、必要に応じて phpcs などのツールを使用してそれらを強制します。
はい、理想的には、言語によって、起こりうる間違いを防ぐことが望まれます。 しかし、それは単に現実的な期待ではありません。 私にとって、それはまだこの RFC に反対票を投じるための議論ではありません。 私は何年もの間、開発者のチームと協力してきましたが、いずれにせよプロジェクトの規約を確立する必要があります。 彼らはうまく動作します。
# PHP 自身の遺産を扱う
ポップクイズ！ 今から 2 時間後に有効期限が切れる、値のない Cookie を設定する方法は?
ドキュメントを調べたり、IDE を参照したりしましたか?
それは結構です、結局のところ、それは紛らわしい機能です。 ただし、名前付き引数を使用すると、もう少し明確になります。 次の 2 つの表記を比較します。
setcookie(
'test',
'',
time() + 60 * 60 * 2
);または：
setcookie(
name: 'test',
expires: time() + 60 * 60 * 2,
);どちらを選ぶかはわかっています。この場合、誰もが名前付き引数の恩恵を受けます。 また、PHP の内部関数がすぐに変更される可能性はほとんどないため、追加するもう 1 つの非常に正当な理由です。
# 他の言語を見る
最後に、単純な事実に直面しましょう。他のいくつかの言語 (多くは Web 開発にも焦点を当てています) は、名前付き引数を既にサポートしています。 わずかに異なる方法でそれらを扱う人もいますが、基本概念は他の多くのプログラマーに知られており、それは良いことです.
以下にいくつかの例を示します。
ですから、保守が困難なコードや、保守が困難になるオープン ソース ソフトウェアについての恐怖を広めないようにしましょう。 名前付き引数は、より大きなソフトウェア コミュニティでは既知の機能であり、その価値が証明されています。 仮定の問題は必要ありません。
ちなみに、この時点で投票は通過します！ 名前付き引数については、このブログで詳しく読むことができます。