On Sat, Jun 11, 2022, at 5:01 PM, Deleu wrote:
> On Sat, Jun 11, 2022 at 11:14 PM Rowan Tommins <rowan.coll...@gmail.com>
> wrote:
>
>> On 09/06/2022 17:34, Larry Garfield wrote:
>> > Last year, Nuno Maduro and I put together an RFC for combining the
>> multi-line capabilities of long-closures with the auto-capture compactness
>> of short-closures ... Arnaud Le Blanc has now picked up the flag with an
>> improved implementation ... The RFC has therefore been overhauled
>> accordingly and is now ready for consideration.
>> >
>> > https://wiki.php.net/rfc/auto-capture-closure
>>
>>
>> They may sound like the same thing, but to me "short closure syntax"
>> (and a lot of the current RFC) implies that the new syntax is better for
>> nearly all closures, and that once it is introduced, the old syntax
>> would only really be there for compatibility - similar to how the []
>> syntax replaces array() and list(). If that is the aim, it's not enough
>> to assert that "the majority" of closures are very short; the syntax
>> should stand up even when used for, say, a middleware handler in a
>> micro-framework. As such, I think we need additional features to opt
>> back out of capturing, and explicitly mark function- or block-scoped
>> variables.
>>
>
> The RFC does mention that the existing Anonymous Function Syntax remains
> untouched and will not be deprecated. Whether the new syntax is better for
> nearly all closures will be a personal choice. If the new syntax doesn't
> suit, say, a middleware handler, then we still can:
> - reach for the old syntax
> - use invocable classes
> - call another method or function which creates a brand new scope and then
> returns a function/callable.
Correct. If this RFC passes, there will be three equally supported syntaxes
for creating closures:
function ($a) use ($b) {
return $a * $b;
};
fn ($a) => $a * $b;
fn ($a) {
return $a * $b;
};
Which one is appropriate in a given situation is left up to developer judgement.
My own personal position would be
* use fn => where possible
* use fn {} if going mult-line.
* if the body of the closure is more than ~3 lines and is not virtually the
entire wrapping scope, it should be its own named function/method *anyway*, and
the new first-class-callable syntax makes that nice and easy to use.
That is, I would probably not use the manual-capture syntax very often at all.
However, if someone disagrees with me on case 3 it's still there for them if
that's easier in context.
Whether the new syntax is viewed as "adding auto-capture to long closures" or
"adding multi-line support to short closures" is, in the end, a mostly academic
distinction with no practical difference. The resulting syntax is smack in the
middle of the two existing ones. The original RFC from a year ago approached
it from the perspective of the first; The rewritten RFC leans on the second
perspective. The use of both names is mostly a historical artifact of reusing
the old URL. :-) The net result is the same.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
