(jp) =
PHP コミュニティ内で名前付き引数の使用に反対する有名なオープン ソース メンテナーが何人かいます。名前付き引数を使用したくない理由として、保守のオーバーヘッドと下位互換性の問題を挙げています。
これらの議論に少しニュアンスを加えたいと思います。
# 下位互換性の問題の原因は?
主な懸念は、たとえば、フレームワークやオープン ソース パッケージで名前付き引数をサポートすると、変更が破壊されるリスクが高まることです。
このクラスを公開するパッケージまたはフレームワークを想像してください。
class QueryBuilder
public function join(
string $table,
string $leftColumn,
string $rightColumn,
string $type
)
名前付き引数の問題は、ユーザーがこの関数を呼び出した場合、フレームワークはパラメーター名の変更を壊す可能性のある変更として扱う必要があることです。
$query->join(
type: 'left',
table: 'table_b',
leftColumn: 'table_a.id',
rightColumn: 'table_b.table_a_id',
)フレームワークが名前を変更したい場合 leftColumn と rightColumn 単純に left と right、上記のコード — ユーザーランドコード — は壊れます。
つまりね： フレームワークやパッケージは、ユーザーが名前付き引数を使用できないようにすることはできません、それらを禁止する方法はありません。 したがって、オープンソースのメンテナーとして、次のいずれかを行います。
- PHP 8 をサポートするとすぐに、引数名の変更を壊れているものとして扱います。
- 名前付き引数を使用しないようにユーザーに依頼します。 また
- ユーザーがこれらの互換性を破る変更に自分で対処できるようにし、それについて心配する必要はありません。
私自身がオープンソースのメンテナーであること: 私はオプション 3 を選択します。 まず第一に、引数名の変更はめったに起こりません。 2 つ目: 私はユーザーがプロの開発者であり、名前付き引数を使用した場合の結果を知っていると信じています。 彼らは賢い大人です、それは彼らの責任です。
この最初の部分を要約すると、この種の下位互換性の問題を防ぐためにフレームワークができることは、引数名の変更をどのように処理するかについて README にメモする以外にありません。 選択したポリシーに一貫性を持たせれば問題ありません。
# 配列データを処理するためのより明確な構文としての名前付き引数
名前付き引数を使用できる 2 番目の方法は、可変個引数関数と組み合わせて使用することです。これは基本的に、データの配列を渡すための — 私の意見ではよりクリーン — な省略形になります。
$user = User::create(
name: 'Brent',
email: '[email protected]',
company_id: 1,
);これは、可変引数関数とうまく連携する名前付き引数のおかげで可能です。
class User
public function create(...$props)
名前付き引数リストをこの変数に渡す create 関数は次のような配列になります。
[
'name' => 'Brent',
'email' => '[email protected]',
'company_id' => 1,
]上記の例を名前付き引数なしで代わりに配列に書き直すと、次のようになります。
$user = User::create([
'name' => 'Brent',
'email' => '[email protected]',
'company_id' => 1,
]);私は、これら 2 つのアプローチのどちらを好むかを知っています。 免責事項: これは、構文の強調表示が優れており、記述が短いものです。
キッカーは次のとおりです。 そもそもハードコードされた引数名がないため、互換性を破る変更の可能性はありません!
下位互換性の問題のために、オープン ソース パッケージで名前付き引数をサポートできないと主張することについては、もっと慎重になる必要があります。 最初のケースでは、どちらの方法でもできることは何もありません。2 番目のケースでは、変更を壊す危険はありません。
同意しませんか？ 私にメールを送るか、 つぶやき そして、それについてさらに議論することができます。 私は間違っていることが証明されることをオープンにしています。
//platform.twitter.com/widgets.js