I've used to 'options as array' pattern in PHP plenty of times. While it's probably the closest thing to named parameters you can get in that language, it can get kind of ugly and clumsy when you have to validate it.<p><pre><code> function something(array $options, $defaults=array('foo'=>1,'bar'=>2)){
...(array_intersect_key or something)...
}
</code></pre>
Actual named parameters would work <i>so much better</i>.<p>And Wordpress 'solves' this in the plugins API by suggesting using extract(), which converts an array into variables. Which is even worse.
After six years of programming in Python I've almost forgot that there are languages that don't have named function parameters.<p>I remember the horror of working with WINAPI. There are WINAPI functions with 10 or so arguments and I was using Delphi which as far as I remember had no support for dictionary literals, let alone named parameters.
Back in highschool, I wrote an Uno clone for a final project in Java. I ended up encountering a similar issue for when I was defining constructors for Card objects. At some point, I had to cast null as an Object to rid of some ambiguity. Still pretty embarrassed about it.
There is currently an RFC for named parameters in PHP 5.6. The spec looks good and I'm hoping it gets approved.<p><a href="https://wiki.php.net/rfc/named_params" rel="nofollow">https://wiki.php.net/rfc/named_params</a>
The problem with this approach is that you basically lose all IDE support and static code checking - it's a good solution in extreme cases, but I prefer not to use it as the default.