Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93466
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.169 as permitted sender)
Content-Type: text/plain; charset=koi8-r; format=flowed; delsp=yes
To: "Levi Morrison" <levim@php.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
References: <op.yhw6ft0mc9evq2@nikita-work-box>
 <CAFMT4NrXPDrjOTda_0nL-1AL7MvkK=DC32XTQwktsrAMGM687A@mail.gmail.com>
 <5388A629-AA48-4CB8-8106-90BAA9B9F227@gmail.com>
 <CAFMT4NrmZ9=M97JhhhFm+A7Sca-XF43Q7KaCzqgPHEsvbmn39A@mail.gmail.com>
Date: Tue, 24 May 2016 08:58:48 +0300
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID: <op.yhydkajkc9evq2@nikita-pc>
In-Reply-To: <CAFMT4NrmZ9=M97JhhhFm+A7Sca-XF43Q7KaCzqgPHEsvbmn39A@mail.gmail.com>
User-Agent: Opera Mail/12.17 (Win32)
Subject: Re: [PHP-DEV] [RFC] [Vote] Callable types (now: Callable prototypes)
From: inefedor@gmail.com ("Nikita Nefedov")

On Mon, 23 May 2016 22:52:18 +0300, Levi Morrison <levim@php.net> wrote:

> On Mon, May 23, 2016 at 1:19 PM, Nikita Nefedov <inefedor@gmail.com>  
> wrote:
>>
>>> On 23 May 2016, at 19:31, Levi Morrison <levim@php.net> wrote:
>>>
>>> A quick question before I vote: do callable prototypes allow for
>>> default parameters in the signature? There are examples for having a
>>> function passed that has a default parameters but I am not seeing it
>>> anywhere in the callable prototype definition so I thought I'd ask.
>>
>> Hey Levi,
>>
>> Although it could be done as a later RFC, my stance on it is that  
>> default values don't belong to the prototype of the function.
>>
>> Why I think that callable typehint doesn't need default values for  
>> params is: you either need this parameter to exist and even if there  
>> are cases where you'd like to pass some kind of 'default' value  
>> implicitly, you as a caller shouldn't impose on the callee  
>> responsibility to have this same value in his definition and instead  
>> just pass your argument explicitly... or if you don't need this  
>> parameter (as in you don't plan to pass anything explicitly) then you  
>> should just ask for a function without this parameter as there is  
>> clearly no need for it at all.
>>
>> Moreover I would argue interfaces have it wrong here too: the fact that  
>> default values are part of an interface yet their invariance is not  
>> enforced, yields an interesting sort of possible LSP violation. F.e. if  
>> we have an interface Logger (a completely unreal example but it shows  
>> what can go wrong) with function 'log($message, $level = LOG_DEBUG);'  
>> and a funny implementation that decided to change default value of  
>> $level to LOG_ALERT, then all callers of Logger#log who relied on the  
>> fact that level if not specified, will be LOG_DEBUG, who also happen to  
>> get the funny implementation of Logger will produce unneeded noise in  
>> the logs with their alert level messages which were intended to be  
>> debug messages :(
>
> Please document this restriction in the RFC. I guess I'm the only one
> who expected it to be there since it didn't come up before, but it
> just seems missing. You don't need to take it out of voting for this
> clarification, imo.

Morning,

sure thing, added it in the RFC