Re: [RFC] [Vote] Callable types (now: Callable prototypes)
| From: | Nikita Nefedov | Date: | Mon, 23 May 2016 19:27:42 +0000 |
| Subject: | Re: [RFC] [Vote] Callable types (now: Callable prototypes) | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-93454@lists.php.net to get a copy of this message | ||
Hi Bob,
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.
If you meant accepting function(string $foo){} as an argument
of callable(int) parameter without coercing then this would
be impossible due the fact that this all is context-dependent.
Which means that the function which got function(string $foo){}
in place of callable(int) could itself be strict-mode
and when it would call this function it would raise a TypeError.
On Mon, 23 May 2016 20:05:50 +0300, Bob Weinand <bobwei9@hotmail.com> wrote:
Hey, I have a question regarding strict/weak types. Currently, you cannot pass a callable function(string $foo) {} to a signature requiring (callable(int)), if I understood the code correctly. But weak types actually should allow that as it's totally fine to pass an integer to a string in weak mode. Is there any particular reason to this seemingly arbitrary restriction? BobAm 23.05.2016 um 16:27 schrieb Nikita Nefedov <inefedor@gmail.com>: 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)