[RFC] [Vote] Callable types (now: Callable prototypes)

> >> On 23 May 2016, at 19:31, Levi Morrison <levim@php.net> wrote: >> >>> On Mon, May 23, 2016 at 8:27 AM, Nikita Nefedov <inefedor@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 :(

> When you pass an `int` to a `string` type parameter in weak mode > it's being coerced to the needed type (not just directly passed). > > This is quite complex, because you'd need to copy zend_function > and all its members (without changing the original zend_function). > > I would love to support it but all in all it comes down to > implementation here for me, so I'd rather do it in a separate > RFC.