<story><title>Named arguments are coming in PHP 8</title><url>https://stitcher.io/blog/php-8-named-arguments</url></story><parent_chain><item><author>arcosdev</author><text>Why not use a dictionary or parameter object when you get past 2 arguments? Or is that not a thing in PHP?</text></item><item><author>Aeolun</author><text>&amp;gt; break the function signature into one-line-per-parameter, which is vile&lt;p&gt;Speak for yourself. If each line indicates what it is the parameter for I couldn’t care less.&lt;p&gt;Nobody will use this for functions that have just two parameters. It’s the ones that have 10 possibilities that are crazy.</text></item><item><author>thaumaturgy</author><text>I&amp;#x27;m ambivalent.&lt;p&gt;There&amp;#x27;s a tension in PHP-land between PHP&amp;#x27;s roots as a low-ish level, get-it-done, hackish language, with its big standard library and simple scalar types, and the better-organized and quite vocal developers who want it to be more Java-like, with great big frameworks and many deeply-nested complex class hierarchies. Instead of unwieldy hobbyist-hacker balls of mud, you build enterprise-scale balls of mud.&lt;p&gt;Named arguments don&amp;#x27;t do a lot for the first group. It looks like the big point in favor is not having to look up a reference for which-arguments-go-where in functions anymore, but a good IDE already does that for you.&lt;p&gt;But there is a common anti-pattern where you have some polymorphic function or interface, and you want to accrete your arguments somewhere and then bundle them up and call the function, so then you see things like [1]:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    call_user_func($function, [&amp;#x27;length&amp;#x27; =&amp;gt; $n, &amp;#x27;foo&amp;#x27; =&amp;gt; $bar, ...]);
&lt;/code&gt;&lt;/pre&gt;
...and &lt;i&gt;that&lt;/i&gt; is bad because it totally bypasses all of PHP&amp;#x27;s type-checking and leaves it up to the called function to sanity-check the input types instead of letting the compiler do it, and basically nobody does that anyway.&lt;p&gt;So named parameters would fix that at least, which would be nice. I&amp;#x27;m just not looking forward to the impact this is going to have on code readability, because everyone (including this article) is going to go, &amp;quot;oh, now my parameter list is too long!&amp;quot;, and break the function signature into one-line-per-parameter, which is vile.&lt;p&gt;[1]: I&amp;#x27;m guilty of this too.</text></item></parent_chain><comment><author>raziel2p</author><text>With a dictionary (array in PHP) you lose strict typing and it&amp;#x27;s possible for the person constructing it to make a typo and it won&amp;#x27;t cause an error, the called function will just think an optional argument was left out.&lt;p&gt;Writing and maintaining parameter classes is just tedious.</text></comment>
<story><title>Named arguments are coming in PHP 8</title><url>https://stitcher.io/blog/php-8-named-arguments</url></story><parent_chain><item><author>arcosdev</author><text>Why not use a dictionary or parameter object when you get past 2 arguments? Or is that not a thing in PHP?</text></item><item><author>Aeolun</author><text>&amp;gt; break the function signature into one-line-per-parameter, which is vile&lt;p&gt;Speak for yourself. If each line indicates what it is the parameter for I couldn’t care less.&lt;p&gt;Nobody will use this for functions that have just two parameters. It’s the ones that have 10 possibilities that are crazy.</text></item><item><author>thaumaturgy</author><text>I&amp;#x27;m ambivalent.&lt;p&gt;There&amp;#x27;s a tension in PHP-land between PHP&amp;#x27;s roots as a low-ish level, get-it-done, hackish language, with its big standard library and simple scalar types, and the better-organized and quite vocal developers who want it to be more Java-like, with great big frameworks and many deeply-nested complex class hierarchies. Instead of unwieldy hobbyist-hacker balls of mud, you build enterprise-scale balls of mud.&lt;p&gt;Named arguments don&amp;#x27;t do a lot for the first group. It looks like the big point in favor is not having to look up a reference for which-arguments-go-where in functions anymore, but a good IDE already does that for you.&lt;p&gt;But there is a common anti-pattern where you have some polymorphic function or interface, and you want to accrete your arguments somewhere and then bundle them up and call the function, so then you see things like [1]:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    call_user_func($function, [&amp;#x27;length&amp;#x27; =&amp;gt; $n, &amp;#x27;foo&amp;#x27; =&amp;gt; $bar, ...]);
&lt;/code&gt;&lt;/pre&gt;
...and &lt;i&gt;that&lt;/i&gt; is bad because it totally bypasses all of PHP&amp;#x27;s type-checking and leaves it up to the called function to sanity-check the input types instead of letting the compiler do it, and basically nobody does that anyway.&lt;p&gt;So named parameters would fix that at least, which would be nice. I&amp;#x27;m just not looking forward to the impact this is going to have on code readability, because everyone (including this article) is going to go, &amp;quot;oh, now my parameter list is too long!&amp;quot;, and break the function signature into one-line-per-parameter, which is vile.&lt;p&gt;[1]: I&amp;#x27;m guilty of this too.</text></item></parent_chain><comment><author>webignition</author><text>I&amp;#x27;d think that such a solution doesn&amp;#x27;t solve but merely moves the problem.&lt;p&gt;A method with N arguments, where N &amp;gt; 2, with a call that is messy due to the number of arguments could instead take a single argument being a parameter object where the constructor for the parameter object takes the same N arguments.&lt;p&gt;A constructor with N arguments with a call that is messy due to the number of arguments ...</text></comment>