Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105131
To: Internals <internals@lists.php.net>
References: <CAHE1EdtbMsGy-TSJNvrHYcUKq=KamekJOd1+9AOV4ME2VB1j+w@mail.gmail.com>
 <CALGLHq189gZfSu0m-5D6VbcS5_ABkWi2sKjRE5ZQpfyFScOsDw@mail.gmail.com>
 <a544f63e-946f-1cfd-8411-9b4a0d36b18f@gmail.com>
 <00ab01d4ecfe$e0b03680$a210a380$@jhdxr.com>
 <CBDB7A0E-A971-4B6F-A66E-950BA4F0DFD4@gmail.com>
 <CALGLHq3Vz9UNXLBD5WxT0sPwW+tb_VQsV2zFZqS0=q+6j5=Ktw@mail.gmail.com>
Message-ID: <831b949a-f2e5-635a-c83b-e936a9f34cc7@gmail.com>
Date: Sun, 7 Apr 2019 13:33:58 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <CALGLHq3Vz9UNXLBD5WxT0sPwW+tb_VQsV2zFZqS0=q+6j5=Ktw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] Parameter skipping
From: rowan.collins@gmail.com (Rowan Collins)

On 07/04/2019 11:53, Morgan Breden wrote:
> >In order to use named parameters, somebody needs to have declared 
> what those names are, and made them a stable API. If they're 
> automatically supported on existing functions, the author might not 
> intend them to be used, or even realise they can, so not keep them 
> stable (I tend to think of parameter names as local, not contractual).
>
> Wouldn't using the name of the variable that is already used for its 
> function signature work perfectly fine for this?
> This is how IDEs already hint for function call completion.


Yes, that's what I meant by "automatically supported on existing 
functions". The problem I was highlighting is that right now, I can 
write this in version 1.0.0 of a library:

function foo($id) {
     $blobId = $id;
     doSomething($blobId);
}

And change it to this in version 1.0.1, without violating SemVer:

function foo($blobId) {
     doSomething($blobId);
}

The name of the parameter is an implementation detail, not a contract. 
If named parameters are automatic, that suddenly becomes a breaking 
change, and either every library author recognises that and avoids such 
changes, or every library user has to check documentation to see if it's 
safe to use named parameters.

Worse, as highlighted in the 2013 RFC, parameter names aren't checked 
when over-riding a method, like this:

interface Fooable { public function foo(int $id); }
class Blob implements Fooable { public function foo(int $blobId) { ... } }

So either the first version of PHP to support named parameters would 
require library authors to change any such code, or again the library 
user has to check if it's safe to use named parameters.

The alternative is to make named parameters opt-in on the part of the 
function author, using extra syntax in the function declaration. I think 
that's a better approach, but probably means an even longer wait until 
libraries introduce it.

So realistically, even if named arguments were added right now, they 
couldn't reliably be used to skip over default parameters in existing 
functions.

None of this is a problem with a simple "default" keyword, which would 
work reliably with all existing function signatures where a default is 
defined, and require no change in code or practice on the part of 
library authors, so can be introduced right now, and used straight away.

Regards,

-- 
Rowan Collins
[IMSoP]