Re: [PHP-DEV] RFC [Discussion]: Closure self-reference
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 confusing about the usage of "use/as" but it also shouts out for the ones reading the code that this function is calling itself. Best regards, Erick Em ter., 6 de jun. de 2023 às 11:26, Bruce Weirdan escreveu: > 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. This has a large aesthetic downside of > appearing to create the closure variable in the scope that the closure is > declared in, rather than internal to the closure scope. > > Does this mean that the variable wouldn't actually be created in the > enclosing scope, but someone may *think* it would? > > > -- > Best regards, > Bruce Weirdan mailto: > weir...@gmail.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] [VOTE] mb_str_pad
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 grapheme_str_pad instead and I'd > like to avoid having both the mb_ and grapheme_ versions which unnecessarily > confuses users. > > I guess I should have spoken up before but I couldn't think of a use case for > padding characters instead of graphemes. Or am I missing something? > > - Chris > Thanks for explaining, I appreciate that. String padding is naturally often associated with display. The use-cases I had in mind are rather more related to data formats, protocols and/or standards. Although a lot of users who hand-rolled their own mb_str_pad misuse it for display purposes, there are use-cases that do indeed use it for the purposes I described above. Some random examples I found using GH code search: * https://github.com/WPPlugins/estonian-banklinks-for-woocommerce/blob/5f97891cfb43d9bde6017243998a3ab424f43b93/includes/gateways/class-wc-banklink-estcard-gateway.php#L139 * https://github.com/ExaByt3s/fodyo/blob/eefdec7da76c820e90987b32baf2aef5ea8d6ca2/bitrix/modules/sale/lib/tradingplatform/vk/feed/data/converters/product.php#L179 * https://github.com/mbence/csaladsegito/blob/20e639b1865ac2ba6be8fc64f69ba9e6f474ef0f/src/JCSGYK/AdminBundle/Services/ClosingService.php#L381 I heard the grapheme argument two times before, one time on the list and one time on Reddit. I do think it's primarily a documentation problem. One problem may be though that a non-negligible number of users probably don't read documentation. The fact that this comes up again gives me a little bit of fear whether the function would cause confusion. So I'm keeping my ears open for concerns. For visual purposes I'm also not sure if a grapheme variant would fully suffice, as it would also require the grapheme to be fixed width. But that's another issue of course. Kind regards Niels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC [Discussion]: Closure self-reference
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. This has a large aesthetic downside of appearing > to create the closure variable in the scope that the closure is declared in, > rather than internal to the closure scope. Does this mean that the variable wouldn't actually be created in the enclosing scope, but someone may *think* it would? -- Best regards, Bruce Weirdan mailto:weir...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC [Discussion]: Closure self-reference
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 is imho more idiomatic and ergonomic than the other proposals. Keywords naturally avoid conflicts with user variables, and remove the need for each author to pick a name for their closure and the inevitable preferences, automation, and disagreements that will arise from that. On the other hand, we've seen from *match()* how disruptive a new keyword can be as they clash as well, with function names instead of variables. Building on an existing keyword or soft-reserved naming convention would avoid that. In terms of global constants, we have double underscores which is in the proposal already but feels unnatural as others have indicated already. In terms of local constants, I believe we authors generally prefer uppercase names, and we have one built-in special constant that's lowercase: *self::class*. Perhaps *self::fn* or *self::callee*? The latter borrows the closure terminology form JavaScript (arguments.callee, which does the same thing). -- Timo Tijhof https://timotijhof.net/
[PHP-DEV] make FILE_ constants not collide with LOCK_
Can I get some attention to https://github.com/php/php-src/pull/11254 ? It's been 3 weeks and nothing so far
Re: [PHP-DEV] [RFC] [VOTE] mb_str_pad
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 grapheme_ versions which unnecessarily confuses users. I guess I should have spoken up before but I couldn't think of a use case for padding characters instead of graphemes. Or am I missing something? - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
