On Mon, May 23, 2016 at 1:19 PM, Nikita Nefedov <inefe...@gmail.com> wrote: > >> On 23 May 2016, at 19:31, Levi Morrison <le...@php.net> wrote: >> >>> On Mon, May 23, 2016 at 8:27 AM, Nikita Nefedov <inefe...@gmail.com> wrote: >>> Evening internals, >>> >>> With this message I'd like to go to vote >>> with the Callable prototypes RFC targeted at 7.1: >>> https://wiki.php.net/rfc/callable-types >>> >>> We've renamed it (previously was "Callable types") as RFC names often >>> dictate how users will call the feature and I want it to be more >>> accurate/descriptive. >>> >>> Also the reflection part was added although I'm short on time currently, >>> so implementation for that will be ready later. (speaking of implementation, >>> it also currently doesn't use cache_slots - also something I'll add when >>> I have a little bit of time) >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php >> >> 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
