Hello you all.
As closures are objects, I'd be ok with $this->__invoke(), but it's not
possible because closures can be bound to other contexts.
>From the proposed solutions, the one that makes more sense to me is the
__CLOSURE__, because not only it does not need
the boilerplate that can be
Hi Christian
On 06/06/2023 09:12, Christian Schneider wrote:
> Am 05.06.2023 um 19:59 schrieb Niels Dossche :
>> I'm opening the vote now on my proposal to include mb_str_pad() into PHP 8.3.
>> RFC link: https://wiki.php.net/rfc/mb_str_pad
>
> I voted "No" because I think it should be
On Sat, Jun 3, 2023 at 9:11 PM Dan Ackroyd wrote:
> I'm now opening the discussion for the Closure self-reference RFC:
> https://wiki.php.net/rfc/closure_self_reference
Looking at the syntax options on the RFC page, the following
explanation is not clear to me:
> * De-anonymize the function.
On Mon, 5 Jun 2023 at 05:09, Alexandru Pătrănescu
wrote:
>
> How about a keyword/variable to the current executing closure that works
> also if you refactor it to a function or a method.
> Just like self for a class we can have a keyword like fnself [..]
This seems quite appealing to me, and
Can I get some attention to https://github.com/php/php-src/pull/11254
? It's been 3 weeks and nothing so far
Am 05.06.2023 um 19:59 schrieb Niels Dossche :
> I'm opening the vote now on my proposal to include mb_str_pad() into PHP 8.3.
> RFC link: https://wiki.php.net/rfc/mb_str_pad
I voted "No" because I think it should be grapheme_str_pad instead and I'd like
to avoid having both the mb_ and
