Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2

[Mike Schinkel]

> On Mar 25, 2021, at 1:57 PM, Rowan Tommins  wrote:
> 
> On 25/03/2021 17:14, Mike Schinkel wrote:
>> Are you proposing auto-capture but one that is note able to change the 
>> variable's value in the outer scope?
> 
> 
> I'm not proposing that, Nuno is. That's what this RFC proposes.

Your earlier comment confused me. I thought you were describing a genuine 
concern when you mentioned by-value — so I assumed the RFC had asked for by-ref 
even though I did not think it had. 

But instead you were being disingenuous by not answering a legitimate question 
and instead implying that those who support the RFC lack reason and that they 
should just accept the status quo (copied below for reference):

> On Mar 25, 2021, at 12:50 PM, Rowan Tommins  wrote:
> On 25/03/2021 15:02, Mike Schinkel wrote:
>> Can you please clarify why "function(...) use(...) {...}" can't be their 
>> solution when someone needs by-reference capture?
> For the same reason - or lack of reason - why it can't be the solution when 
> they need by-value capture. In other words, whatever reason people have for 
> wanting this RFC.

Instead, why not simply state your position against the RFC transparently — as 
you eventually did in another reply — and leave it at that?  Then the deciders 
can go off and make their decisions on the RFC as they will.


-Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2

[Mike Schinkel]

> On Mar 25, 2021, at 4:09 PM, Olle Härstedt  wrote:
> 
> 2021-03-25 17:49 GMT+01:00, Mike Schinkel :
>>> On Mar 25, 2021, at 11:22 AM, Olle Härstedt 
>>> wrote:
>>> 
>>> 2021-03-25 16:02 GMT+01:00, Mike Schinkel :
 
 
> On Mar 25, 2021, at 10:41 AM, Rowan Tommins 
> wrote:
> 
> On 25/03/2021 12:31, Nuno Maduro wrote:
> 
>> The reason why we believe the vast majority of PHP Developers are
>> going
>> to
>> appreciate this RFC is because multi-line short closures (aka
>> Auto-capturing multi-statement closures) *are more simple, shorter to
>> write, and prettier to read *— and the community love these changes as
>> proven on "property promotions", "one-line short closures", etc.
> 
> 
> My main point was that the RFC needs to spell out this argument, rather
> than taking it for granted that everyone agrees on "those situations
> where
> that is warranted".
> 
> Most of the current text should be summarised in a "syntax choices"
> section somewhere near the end. I would like to see much more space
> devoted to:
> 
> * Why we need this feature. What has changed since it was left out of
> the
> arrow functions RFC? What problems is it addressing? Why do you think
> it
> is the best approach to those problems?
> * The exact semantics proposed: How will the variables to be captured
> be
> determined? Will it distinguish variables which are written before
> they're
> read, and if so how is that defined? Can auto-capturing closures be
> nested, i.e. will "fn() { return fn() { echo $a; } }" capture $a from
> the
> outermost scope? And so on...
> 
> 
>> Besides, one advantage of this RFC is that it is consistent with the
>> current syntax of the language and with the short-functions RFC[2].
>> For
>> example, by proposing that "fn" keyword indicates a function will
>> auto-capture variables, by value.
> 
> 
> While it's a cute rationalisation, there's no intuitive reason why "fn"
> should have that meaning; we could pick any aspect of the current arrow
> function syntax and say "the 'fn' keyword means that".
> 
> 
> 
>> On the other hand "use (*)" has no usages / or current meaning in the
>> language.
> 
> 
> This is a straw man argument. I could equally say that "fn() { } has no
> usages or current meaning in the language" - of course it doesn't, we
> haven't added it yet!
> 
> The "function use() {}" part of "function use(*) {}" has a
> well-established meaning, and "*" to mean "everything" is a notation
> developers are likely to be very familiar with.
> 
> The two disadvantages I see with using "fn" as proposed are:
> 
> * Because it's shorter, people will decide it's the "better" version,
> when
> they don't actually need any variable capture. An explicit syntax like
> "use(*)" instead makes this a deliberate choice.
 
 And yet adding " use (*)" makes the syntax longer, which goes against one
 of
 the goals many people have for it: to be shorter.
>>> 
>>> I don't understand why this is a target in the first place. Shorter
>>> does not mean more readable, and readable is more important than
>>> writable.
>> 
>> I agree that readable is more important than writable, but shorter also does
>> not necessarily mean it is *less* readable, either.
> 
> Sure. The brain removes noise and reads in "symbols" anyway (where
> "fn" or "function" is a symbol of size 1).

That is actually not exactly true, at least not in all cases. 

When "nction" combined with " use (.)" adds to line length such that a 
developer must scroll horizontally to see all the text then it is not the same. 

And this is not a hypothetical for those of us who frequently use vertical 
split screen in our editors — I am constantly battling with lines that are too 
long.

Also when longer lines cause code to wrap on GitHub or in blog posts or other 
places then it is not the same.

> A more important aspect of readability is the cognitive load on
> short-term memory, or how many "chunks" the programmer has to keep in
> memory to understand a piece of code. In this case, I think
> immutability and local scope helps a lot, of which PHP has neither. Or
> maybe predictability of the scope? All language quirks hurt
> readability. I never had a problem with scope in JS, despite it
> lacking immutability and only recently got proper block scope.

Given that the RFC prescribes by-value capture and not by-ref capture how it is 
really even a problem?  Or are you arguing that you fear people will just write 
closures hundreds of lines long?

Maybe PHP should deprecate functions longer than 50 or 100 lines?  

> Maybe more important than explicit/implicit capturing of scope is to
> keep your functions short...? In our legacy code-base, we have functions
> thousand

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2

[Olle Härstedt]

2021-03-25 17:49 GMT+01:00, Mike Schinkel :
>> On Mar 25, 2021, at 11:22 AM, Olle Härstedt 
>> wrote:
>>
>> 2021-03-25 16:02 GMT+01:00, Mike Schinkel :
>>>
>>>
 On Mar 25, 2021, at 10:41 AM, Rowan Tommins 
 wrote:

 On 25/03/2021 12:31, Nuno Maduro wrote:

> The reason why we believe the vast majority of PHP Developers are
> going
> to
> appreciate this RFC is because multi-line short closures (aka
> Auto-capturing multi-statement closures) *are more simple, shorter to
> write, and prettier to read *— and the community love these changes as
> proven on "property promotions", "one-line short closures", etc.


 My main point was that the RFC needs to spell out this argument, rather
 than taking it for granted that everyone agrees on "those situations
 where
 that is warranted".

 Most of the current text should be summarised in a "syntax choices"
 section somewhere near the end. I would like to see much more space
 devoted to:

 * Why we need this feature. What has changed since it was left out of
 the
 arrow functions RFC? What problems is it addressing? Why do you think
 it
 is the best approach to those problems?
 * The exact semantics proposed: How will the variables to be captured
 be
 determined? Will it distinguish variables which are written before
 they're
 read, and if so how is that defined? Can auto-capturing closures be
 nested, i.e. will "fn() { return fn() { echo $a; } }" capture $a from
 the
 outermost scope? And so on...


> Besides, one advantage of this RFC is that it is consistent with the
> current syntax of the language and with the short-functions RFC[2].
> For
> example, by proposing that "fn" keyword indicates a function will
> auto-capture variables, by value.


 While it's a cute rationalisation, there's no intuitive reason why "fn"
 should have that meaning; we could pick any aspect of the current arrow
 function syntax and say "the 'fn' keyword means that".



> On the other hand "use (*)" has no usages / or current meaning in the
> language.


 This is a straw man argument. I could equally say that "fn() { } has no
 usages or current meaning in the language" - of course it doesn't, we
 haven't added it yet!

 The "function use() {}" part of "function use(*) {}" has a
 well-established meaning, and "*" to mean "everything" is a notation
 developers are likely to be very familiar with.

 The two disadvantages I see with using "fn" as proposed are:

 * Because it's shorter, people will decide it's the "better" version,
 when
 they don't actually need any variable capture. An explicit syntax like
 "use(*)" instead makes this a deliberate choice.
>>>
>>> And yet adding " use (*)" makes the syntax longer, which goes against one
>>> of
>>> the goals many people have for it: to be shorter.
>>
>> I don't understand why this is a target in the first place. Shorter
>> does not mean more readable, and readable is more important than
>> writable.
>
> I agree that readable is more important than writable, but shorter also does
> not necessarily mean it is *less* readable, either.

Sure. The brain removes noise and reads in "symbols" anyway (where
"fn" or "function" is a symbol of size 1).

A more important aspect of readability is the cognitive load on
short-term memory, or how many "chunks" the programmer has to keep in
memory to understand a piece of code. In this case, I think
immutability and local scope helps a lot, of which PHP has neither. Or
maybe predictability of the scope? All language quirks hurt
readability. I never had a problem with scope in JS, despite it
lacking immutability and only recently got proper block scope. Maybe
more important than explicit/implicit capturing of scope is to keep
your functions short...? In our legacy code-base, we have functions
thousands of lines long. I can see auto-capturing being a problem
there, but that's because of the technical debt and not the feature
itself, I guess. Will our juniors realize that, tho?

Never the less, the need to include 5+ variables in your closure -
code smell? I stated above that command pattern and data-transfer
objects are probably better, and that's why I think the example in the
RFC is not motivating enough.

The question is not "what do I want to be able to write", but rather
"what do I want to be forced to read [by less qualified programmers]".

> For some people, shorter makes it more readable because there is less to
> read and more whitespace surrounding it. Ironically readability is why I
> prefer fn() w/autocapture over "function(...) use (...) {...}."
>
> Also, it appears you may be discounting that readablity evolves as people's
> familiarity with a new syntax increases.  For example, I found RegEx
> completely unreadable for a long ti

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2

[Mike Schinkel]

> On Mar 25, 2021, at 1:19 PM, Chase Peeler  wrote:
> 
> On Thu, Mar 25, 2021 at 1:14 PM Mike Schinkel  > wrote:
> > On Mar 25, 2021, at 12:50 PM, Rowan Tommins  > > wrote:
> > 
> > On 25/03/2021 15:02, Mike Schinkel wrote:
> >> Can you please clarify why "function(...) use(...) {...}" can't be their 
> >> solution when someone needs by-reference capture?
> > 
> > 
> > For the same reason - or lack of reason - why it can't be the solution when 
> > they need by-value capture. In other words, whatever reason people have for 
> > wanting this RFC.
> 
> Are you proposing auto-capture but one that is note able to change the 
> variable's value in the outer scope?  
> 
> Since code is worth 1000 words, here is an example of what I think you are 
> saying:
> 
> $x = 1;
> example(fn() {
>echo $x; // This would print "1"
>$x = 2;
>echo $x; // This would print "2"
> });
> echo $x;  // This would still print "1"
> 
> If that is what you are saying — which I did not get from your prior 
> arguments — then I myself would be fine with "by-value" capture.
> 
> What I like about the RFC is being able to omit the use(...) when referencing 
> (reading) a variable inside the closure that come from the outer scope.  But 
> almost all of my use-cases would work fine with by-value semantics, and for 
> the rest I could use "function(...)use(...){...}."
> 
> That said, I again suggest this we could omit the "use" keyword for short 
> functions:  
> 
> // 2nd set of parens acts as an implied "use":
> example( fn()(&$var) => $var = value() );
> 
> 
> That wouldn't work though if example expects a callback with a defined 
> signature. "Use function() use()" in that case might be a valid solution, but 
> just wanted to throw it out there.


True.  But is that really any different than this failing:

example(1);

When the signature is this?

example(string $x) {...}

-Mike

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2

[Rowan Tommins]

On 25/03/2021 17:14, Mike Schinkel wrote:

Are you proposing auto-capture but one that is note able to change the 
variable's value in the outer scope?



I'm not proposing that, Nuno is. That's what this RFC proposes.


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2

[Rowan Tommins]

On 25/03/2021 17:11, Chase Peeler wrote:
I don't think you should keep a function from developers because some 
people might use it incorrectly.



That is not what I said either.

I said I am not a fan of the "fn" syntax, because I do not think 
auto-capture should be seen as the default.


If consensus is that we need auto-capture in the language, I would 
prefer a syntax that clearly shows that you are opting into it.



Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures andshortfunctions take 2

[Chase Peeler]

On Thu, Mar 25, 2021 at 10:38 AM Olle Härstedt 
wrote:

> 2021-03-25 15:23 GMT+01:00, Christian Schneider :
> > Am 25.03.2021 um 14:29 schrieb Mark Randall :
> >> On 25/03/2021 09:28, Rowan Tommins wrote:
> >>> That's not quite what I meant. I meant that you can't say "capture by
> >>> default, but this variable is definitely local".
> >>
> >> I think if there's one argument against, this would be it, but IMHO it
> is
> >> a weakness in PHP as a whole.
> >
> > I'm not sure if I misunderstand what you're saying but to me it is one of
> > the greatest things about PHP that everything is local by default (minus
> a
> > narrow set of well-known and easily enough recognizable things).
> >
> >> The solution would be adding JS-like let / const statements. Which would
> >> be a benefit to other things too.
> >
> >
> > I disagree that this is the solution. I think JS had to add var and later
> > let because of the unfortunate decision to have C-like scoping rules.
> > Making scoping in PHP more complex to be able to repeat this mistake in
> some
> > form seems ill-advised to me.
> >
> > - Chris
>
> You could make the change that *all* variables are now block-scoped,
> not function-scoped. That would make auto-capture less dangerous, but
> I don't know how much code it would break.
>
>
The BC implications would be huge, not to mention that it wouldn't be a
good idea anyway (at least in my opinion). The following would no longer
work:

if($check){
  $match = true;
} else {
  $match = false;
}

//stuff

if($match){...}

Yes, that could be done in a way that works with block scoping, but the
fact that PHP has never been blocked scoped means there would be a LOT of
code that would break if it was.



> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2

[Chase Peeler]

On Thu, Mar 25, 2021 at 1:14 PM Mike Schinkel  wrote:

> > On Mar 25, 2021, at 12:50 PM, Rowan Tommins 
> wrote:
> >
> > On 25/03/2021 15:02, Mike Schinkel wrote:
> >> Can you please clarify why "function(...) use(...) {...}" can't be
> their solution when someone needs by-reference capture?
> >
> >
> > For the same reason - or lack of reason - why it can't be the solution
> when they need by-value capture. In other words, whatever reason people
> have for wanting this RFC.
>
> Are you proposing auto-capture but one that is note able to change the
> variable's value in the outer scope?
>
> Since code is worth 1000 words, here is an example of what I think you are
> saying:
>
> $x = 1;
> example(fn() {
>echo $x; // This would print "1"
>$x = 2;
>echo $x; // This would print "2"
> });
> echo $x;  // This would still print "1"
>
> If that is what you are saying — which I did not get from your prior
> arguments — then I myself would be fine with "by-value" capture.
>
> What I like about the RFC is being able to omit the use(...) when
> referencing (reading) a variable inside the closure that come from the
> outer scope.  But almost all of my use-cases would work fine with by-value
> semantics, and for the rest I could use "function(...)use(...){...}."
>
> That said, I again suggest this we could omit the "use" keyword for short
> functions:
>
> // 2nd set of parens acts as an implied "use":
> example( fn()(&$var) => $var = value() );
>
>
That wouldn't work though if example expects a callback with a defined
signature. "Use function() use()" in that case might be a valid solution,
but just wanted to throw it out there. Silly example:

$counter = 0;
array_map(fn($a) => {$counter++; return $a+1},$array);

If you tried to pass in $counter as a parameter, it would fail.


> -Mike
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and short functions take 2

[Christian Schneider]

Am 25.03.2021 um 17:25 schrieb Larry Garfield :
> So in conclusion, it seems the reasons closures weren't auto-capture always 
> were:
> 
> 1) Possible performance concerns that are no longer relevant.
> 2) Avoid surprise references.
> 3) Allow users to capture by value or by reference.
> 
> Point 1 is no longer relevant as the engine has changed so much.
> Point 2 is no longer relevant since forever, since capture is by-val by 
> default.
> Point 3 is only relevant in the cases where you need to capture by reference, 
> which in practice it turns out are really quite rare.
> 
> So, I would argue that all of the reasons for manual capture in the first 
> place are no longer relevant, except in the edge case where you really do 
> want to capture by reference.

While the discussion back then revolved a lot around performance and references 
I don't think

4) Local-as-default scoping and explicit captures are the PHP way and make it a 
better language

which was mentioned in this thread should be buried ;-)

- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2

[Mike Schinkel]

> On Mar 25, 2021, at 12:50 PM, Rowan Tommins  wrote:
> 
> On 25/03/2021 15:02, Mike Schinkel wrote:
>> Can you please clarify why "function(...) use(...) {...}" can't be their 
>> solution when someone needs by-reference capture?
> 
> 
> For the same reason - or lack of reason - why it can't be the solution when 
> they need by-value capture. In other words, whatever reason people have for 
> wanting this RFC.

Are you proposing auto-capture but one that is note able to change the 
variable's value in the outer scope?  

Since code is worth 1000 words, here is an example of what I think you are 
saying:

$x = 1;
example(fn() {
   echo $x; // This would print "1"
   $x = 2;
   echo $x; // This would print "2"
});
echo $x;  // This would still print "1"

If that is what you are saying — which I did not get from your prior arguments 
— then I myself would be fine with "by-value" capture.

What I like about the RFC is being able to omit the use(...) when referencing 
(reading) a variable inside the closure that come from the outer scope.  But 
almost all of my use-cases would work fine with by-value semantics, and for the 
rest I could use "function(...)use(...){...}."

That said, I again suggest this we could omit the "use" keyword for short 
functions:  

// 2nd set of parens acts as an implied "use":
example( fn()(&$var) => $var = value() );

-Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2

[Chase Peeler]

On Thu, Mar 25, 2021 at 12:47 PM Rowan Tommins 
wrote:

> On 25/03/2021 15:05, Deleu wrote:
> > > * Because it's shorter, people will decide it's the "better" version,
> > > when they don't actually need any variable capture. An explicit syntax
> > > like "use(*)" instead makes this a deliberate choice.
> >
> > Does this mean you agree that people (PHP users) are very likely to
> > like/enjoy/"think it's the better version", but you still object to it
> > because people will like the new syntax so much that they will use it
> > even when they don't need auto-capture?
>
>
> No, it does not.
>
> I think that people who have no idea how either version of the syntax
> works will decide that the keyword "fn" is easier to type than
> "function", and not realise the far-reaching effect this can have on
> their code.
>
>
I don't think you should keep a function from developers because some
people might use it incorrectly. Make sure it is documented properly and
stop worrying about people that ignore the documentation.


> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures andshortfunctions take 2

[Rowan Tommins]

On 25/03/2021 16:24, Nuno Maduro wrote:

Concerning the comments about what's exactly "auto-captured" by the scope
of a multi-line short closure, we will be just reusing the "auto-capture"
feature that already exists in one-line short closures. Therefore, this RFC
doesn't have plans on changing the way "auto-capture" already works in PHP.



This may be technically true, but it's not particularly helpful. I'm not 
sure if the details are actually documented anywhere, and there's an 
awful lot of PHP code that either can't be used in a single-expression 
closure, or is extremely unlikely to be used.


For instance, which of the following will capture $a?

$assignedBeforeUse = fn() {
    $a = 42;
    echo $a;
}

$unreachableUse = fn() {
    if(false) { echo $a; }
    $a = 42;
}

$assignedBeforeUnreachableUse = fn() {
    $a = 42;
    if(false) { echo $a; }
}

$unsetRatherThanWritten = fn() {
    unset($a);
    echo $a;
}

$outerClosure = fn() {
    $nestedClosure = fn() {
    echo $a;
    }
}


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures andshortfunctions take 2

[Matthew Brown]

On Thu, 25 Mar 2021 at 12:24, Nuno Maduro  wrote:

> Hi,
>
> Concerning the comments about what's exactly "auto-captured" by the scope
> of a multi-line short closure, we will be just reusing the "auto-capture"
> feature that already exists in one-line short closures. Therefore, this RFC
> doesn't have plans on changing the way "auto-capture" already works in PHP.
>

Absolutely, but allowing assignments in short closures increases their
complexity, and thus (in my opinion) erases the advantage of auto-capturing.

I know you can _also_ have assignments in short closures (because
assignments are just expressions in PHP), but it's much harder to come up
with short closure gotchas.

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2

[Rowan Tommins]

On 25/03/2021 15:02, Mike Schinkel wrote:

Can you please clarify why "function(...) use(...) {...}" can't be their 
solution when someone needs by-reference capture?



For the same reason - or lack of reason - why it can't be the solution 
when they need by-value capture. In other words, whatever reason people 
have for wanting this RFC.



Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2

[Mike Schinkel]

> On Mar 25, 2021, at 11:22 AM, Olle Härstedt  wrote:
> 
> 2021-03-25 16:02 GMT+01:00, Mike Schinkel :
>> 
>> 
>>> On Mar 25, 2021, at 10:41 AM, Rowan Tommins 
>>> wrote:
>>> 
>>> On 25/03/2021 12:31, Nuno Maduro wrote:
>>> 
 The reason why we believe the vast majority of PHP Developers are going
 to
 appreciate this RFC is because multi-line short closures (aka
 Auto-capturing multi-statement closures) *are more simple, shorter to
 write, and prettier to read *— and the community love these changes as
 proven on "property promotions", "one-line short closures", etc.
>>> 
>>> 
>>> My main point was that the RFC needs to spell out this argument, rather
>>> than taking it for granted that everyone agrees on "those situations where
>>> that is warranted".
>>> 
>>> Most of the current text should be summarised in a "syntax choices"
>>> section somewhere near the end. I would like to see much more space
>>> devoted to:
>>> 
>>> * Why we need this feature. What has changed since it was left out of the
>>> arrow functions RFC? What problems is it addressing? Why do you think it
>>> is the best approach to those problems?
>>> * The exact semantics proposed: How will the variables to be captured be
>>> determined? Will it distinguish variables which are written before they're
>>> read, and if so how is that defined? Can auto-capturing closures be
>>> nested, i.e. will "fn() { return fn() { echo $a; } }" capture $a from the
>>> outermost scope? And so on...
>>> 
>>> 
 Besides, one advantage of this RFC is that it is consistent with the
 current syntax of the language and with the short-functions RFC[2]. For
 example, by proposing that "fn" keyword indicates a function will
 auto-capture variables, by value.
>>> 
>>> 
>>> While it's a cute rationalisation, there's no intuitive reason why "fn"
>>> should have that meaning; we could pick any aspect of the current arrow
>>> function syntax and say "the 'fn' keyword means that".
>>> 
>>> 
>>> 
 On the other hand "use (*)" has no usages / or current meaning in the
 language.
>>> 
>>> 
>>> This is a straw man argument. I could equally say that "fn() { } has no
>>> usages or current meaning in the language" - of course it doesn't, we
>>> haven't added it yet!
>>> 
>>> The "function use() {}" part of "function use(*) {}" has a
>>> well-established meaning, and "*" to mean "everything" is a notation
>>> developers are likely to be very familiar with.
>>> 
>>> The two disadvantages I see with using "fn" as proposed are:
>>> 
>>> * Because it's shorter, people will decide it's the "better" version, when
>>> they don't actually need any variable capture. An explicit syntax like
>>> "use(*)" instead makes this a deliberate choice.
>> 
>> And yet adding " use (*)" makes the syntax longer, which goes against one of
>> the goals many people have for it: to be shorter.
> 
> I don't understand why this is a target in the first place. Shorter
> does not mean more readable, and readable is more important than
> writable.

I agree that readable is more important than writable, but shorter also does 
not necessarily mean it is *less* readable, either.  

For some people, shorter makes it more readable because there is less to read 
and more whitespace surrounding it. Ironically readability is why I prefer fn() 
w/autocapture over "function(...) use (...) {...}."

Also, it appears you may be discounting that readablity evolves as people's 
familiarity with a new syntax increases.  For example, I found RegEx completely 
unreadable for a long time, but today I find them completely readable because I 
now understand them. Have you already considered whether or not you would still 
find fn() w/autocapture less readable even after you have more time and 
experience seeing it in other people's code, and decided that you would still 
find it less readable?

I do recognize that ever developer has their own preference and I am sensing 
that your preference is for more verbose syntax, at least in this case? If that 
is true shouldn't you just state that more verbose is your preference and if 
you have a vote then vote against the RFC? Isn't it unfair to implictly assert 
that "shorter is less readable" when really it is just a preference?

-Mike

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2

[Rowan Tommins]

On 25/03/2021 15:05, Deleu wrote:

> * Because it's shorter, people will decide it's the "better" version,
> when they don't actually need any variable capture. An explicit syntax
> like "use(*)" instead makes this a deliberate choice.

Does this mean you agree that people (PHP users) are very likely to 
like/enjoy/"think it's the better version", but you still object to it 
because people will like the new syntax so much that they will use it 
even when they don't need auto-capture?



No, it does not.

I think that people who have no idea how either version of the syntax 
works will decide that the keyword "fn" is easier to type than 
"function", and not realise the far-reaching effect this can have on 
their code.


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Release Managers for PHP 8.1

[Ben Ramsey]

> On Mar 1, 2021, at 11:09, Sara Golemon  wrote:
> 
> This is your early, advance warning that RM selection for the PHP 8.1
> branch will be coming up in April.  Please start thinking about whether or
> not you would like to put your hat in the ring. Feel free to volunteer now,
> or any time over the coming weeks.  Additional announcements will be
> forthcoming as we approach the selection date.  On April 12th
> (provisional), Gabriel or I will announce the list of candidates and, if
> more than two candidates have volunteered, open a vote.
> 
> A description of our release process can be found at
> https://github.com/php/php-src/blob/master/docs/release-process.md and
> https://wiki.php.net/rfc/releaseprocess
> 
> Notably, at least one of the volunteers must be a "veteran" release manager
> meaning they have participated in at least one release of PHP in the past.
> The other may be an additional veteran, or more ideally, someone new to the
> RM role (in order to increase our supply of veteran RMs).  Regardless of
> who is participating, you'll have access to all active release managers to
> help get you up and running.
> 
> Let's all make PHP awesome!
> -Sara Golemon and Gabriel Caruso, your PHP 8.0 Release Managers


Wow! I’m excited to see all the new folks interested in volunteering as
an RM. I think that’s a pretty good indication of the health of our
community. :-)

I’ll also toss my hat into the ring for consideration as one of the
newbie 8.1 RMs.

I’ve been building PHP applications for over 20 years, and I’ve been
involved with the community in one form or another for about 17 years.
I’ve written for *php[architect]* and *International PHP Magazine*
(when it was still around), and I co-authored a book with Davey Shafik,
of which I’m currently working (slowly) on a 4th edition, updated for
PHP 8.0 (and maybe 8.1, depending on timing).

When conferences were still a thing, I spoke at many, and I ran a PHP
Community Conference in 2011 in Nashville, TN, US. I’m the author and
maintainer of a number of Composer packages, including ramsey/uuid,
league/oauth2-client, ramsey/composer-repl, and others, and I’ve made a
few small contributions to PHP core over the years.

I’m currently a co-organizer of the Nashville PHP user group and I
helped launch the Atlanta PHP user group over 15 years ago.

I say all this to say that PHP is really important to me, and I would
very much like an opportunity to give back with a material impact on
the core. Furthermore, I want to help the next generation of PHP RMs
and core developers by mentoring and training them, once I’ve learned
the ropes.

Thank you for considering me for the role of RM, and best of luck to all
the other volunteers!

Cheers,
Ben



signature.asc
Description: Message signed with OpenPGP

Re: [PHP-DEV] [RFC] Short functions, take 2

[Larry Garfield]

On Thu, Mar 25, 2021, at 12:12 AM, Peter Stalman wrote:
> On Wed, Mar 24, 2021 at 5:40 PM Larry Garfield 
> wrote:
> 
> > In response to the feedback that the savings in typing volume is small,
> > that's true but also not the main point.  The main point is to allow and
> > encourage functions to be written an in "expression style", that is, as
> > actual functions and not procedures.  As the RFC notes, such use cases are
> > increasing, and is likely to increase in PHP, and that's overall a good
> > thing for the language.  It fits well with a number of recent RFCs both
> > passed and proposed, and makes writing functional-style code much more
> > natural.
> >
> 
> Hi Larry,
> 
> I too am wondering about the space saving aspect; as Levi showed it's quite
> easy to currently write functions on one line, which really only cost 7
> more characters.  Overall though, I am not a fan of the code getting wider,
> and the return statements not lining up as I scroll down the code.

In practice, I've found myself writing arrow functions on 2 lines a lot, like 
this:

$f = fn($a, $b): int
  => $a * $b;

I find that very readable, balances height vs width well, and it's a style very 
popular in functional languages.  I expect a lot of short-function uses to do 
the same, which is a good place to end up.

> As for the "expression style" argument, it's a valid one.  However, I'm
> confused why you submitted this RFC hand-in-hand with the multi-statement
> auto-capture closures.  Doesn't that contradict the single statement
> "expression style" argument?

The short-function RFC was originally written early last fall.  I put it on 
hold because there was also on again/off again discussion of auto-capture 
closures and I was warned to avoid conflicting on the syntax.  I only recently 
got around to connecting with Nuno, who had a PR sitting around for that he'd 
been ignoring for a while, too. :-)

They're separate proposals with their own benefits.  They were (re)-presented 
together mainly to demonstrate that yes, we did think through the syntax to 
ensure that they fit well together and didn't create confusion around what 
certain syntax combinations mean.

> Overall, I'm not really that much against it, but my only worry is that
> while it is slightly less verbose it might create more cluttered code.

Try a lot of 2-line functions as above.  I think you'll find it's actually 
quite nice in practice, which is what I'm going for.

> 
> Thanks,
> Peter
> 
> P.S. I also don't like PSR-12.  Allman braces and tabs for life.

Same-line braces FTW, but don't talk to me about tabs. :-P

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and short functions take 2

[Larry Garfield]

On Thu, Mar 25, 2021, at 12:47 AM, Peter Stalman wrote:
> On Wed, Mar 24, 2021 at 10:15 AM Chase Peeler  wrote:
> 
> > I guess my one question would be why we didn't support auto-capture when we
> > first implemented anonymous functions, and if there was a reason, why does
> > that no longer apply?
> >
> 
> I believe this was the original discussion:
> 
> https://externals.io/message/38290
> 
> Thanks,
> Peter

Thanks!

I just skimmed that thread looking for scope discussions.  I didn't read 
everything so I may have missed a comment somewhere, but the gist seems to be:

* The original proposal included manual capture because it originally was going 
to capture everything by reference, not by value, and so it was seen as "safer" 
to not surprise someone with references leaking about.  (Especially comparisons 
to Javascript.)

* There was mention in the thread of there being a performance advantage of 
manual capture, but I didn't quite follow it.  Also, that was back in 5.3 and 
so much has changed since then in the engine that I would consider any comments 
about performance from that era no longer relevant.

* There was ample debate about what syntax to use for manual capture, but very 
little discussion of whether it should be manual or automatic in the first 
place.

* In the end, we ended up with the use ($byVal, &$byRef) syntax we have 
today... but with the switch to by-val by default there was no discussion of 
whether auto-capture should be used since that was already safer.  Arguably the 
need to differentiate by val or by ref made the explicit list necessary.


So in conclusion, it seems the reasons closures weren't auto-capture always 
were:

1) Possible performance concerns that are no longer relevant.
2) Avoid surprise references.
3) Allow users to capture by value or by reference.

Point 1 is no longer relevant as the engine has changed so much.
Point 2 is no longer relevant since forever, since capture is by-val by default.
Point 3 is only relevant in the cases where you need to capture by reference, 
which in practice it turns out are really quite rare.

So, I would argue that all of the reasons for manual capture in the first place 
are no longer relevant, except in the edge case where you really do want to 
capture by reference.

Which is exactly what the RFC currently says. :-)

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures andshortfunctions take 2

[Nuno Maduro]

Hi,

Concerning the comments about what's exactly "auto-captured" by the scope
of a multi-line short closure, we will be just reusing the "auto-capture"
feature that already exists in one-line short closures. Therefore, this RFC
doesn't have plans on changing the way "auto-capture" already works in PHP.

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures andshortfunctions take 2

[Matthew Brown]

On Thu, 25 Mar 2021 at 10:23, Christian Schneider 
wrote:

> Am 25.03.2021 um 14:29 schrieb Mark Randall :
> > On 25/03/2021 09:28, Rowan Tommins wrote:
> >> That's not quite what I meant. I meant that you can't say "capture by
> default, but this variable is definitely local".
> >
> > I think if there's one argument against, this would be it, but IMHO it
> is a weakness in PHP as a whole.
>
> I'm not sure if I misunderstand what you're saying but to me it is one of
> the greatest things about PHP that everything is local by default (minus a
> narrow set of well-known and easily enough recognizable things).
>
> > The solution would be adding JS-like let / const statements. Which would
> be a benefit to other things too.
>
>
> I disagree that this is the solution. I think JS had to add var and later
> let because of the unfortunate decision to have C-like scoping rules.
> Making scoping in PHP more complex to be able to repeat this mistake in
> some form seems ill-advised to me.
>
> - Chris
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
This is also my feeling. While it's easy to see from the single line

fn ($x, $y)  => $x + $y + $z

that $z is auto-captured, it's much less easy to see that in

fn ($x, $y) {
$x += $y >> 2;
$y = 2 - $y;
$z -= 4;
return $x + $y + $z;
}

Here's an example of this auto-catpuring multi-line functions in use today:
https://github.com/hhvm/hhast/blob/bb0f0445b2e693270079dcced01a29919d87e955/src/Migrations/IsRefinementMigration.hack#L54-L111
I think that code would be more a little more readable with an explicit
closure
function($node, $parents) use ($map) {

Lastly, PHP's handling of arrays adds an auto-capturing gotcha:

   fn ($x, $y) {
$z[] = 1;
return $x + $y + count($z);
}

This is valid whether or not $z is defined before the closure.

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2

[Chase Peeler]

On Thu, Mar 25, 2021 at 11:23 AM Olle Härstedt 
wrote:

> 2021-03-25 16:02 GMT+01:00, Mike Schinkel :
> >
> >
> >> On Mar 25, 2021, at 10:41 AM, Rowan Tommins 
> >> wrote:
> >>
> >> On 25/03/2021 12:31, Nuno Maduro wrote:
> >>
> >>> The reason why we believe the vast majority of PHP Developers are going
> >>> to
> >>> appreciate this RFC is because multi-line short closures (aka
> >>> Auto-capturing multi-statement closures) *are more simple, shorter to
> >>> write, and prettier to read *— and the community love these changes as
> >>> proven on "property promotions", "one-line short closures", etc.
> >>
> >>
> >> My main point was that the RFC needs to spell out this argument, rather
> >> than taking it for granted that everyone agrees on "those situations
> where
> >> that is warranted".
> >>
> >> Most of the current text should be summarised in a "syntax choices"
> >> section somewhere near the end. I would like to see much more space
> >> devoted to:
> >>
> >> * Why we need this feature. What has changed since it was left out of
> the
> >> arrow functions RFC? What problems is it addressing? Why do you think it
> >> is the best approach to those problems?
> >> * The exact semantics proposed: How will the variables to be captured be
> >> determined? Will it distinguish variables which are written before
> they're
> >> read, and if so how is that defined? Can auto-capturing closures be
> >> nested, i.e. will "fn() { return fn() { echo $a; } }" capture $a from
> the
> >> outermost scope? And so on...
> >>
> >>
> >>> Besides, one advantage of this RFC is that it is consistent with the
> >>> current syntax of the language and with the short-functions RFC[2]. For
> >>> example, by proposing that "fn" keyword indicates a function will
> >>> auto-capture variables, by value.
> >>
> >>
> >> While it's a cute rationalisation, there's no intuitive reason why "fn"
> >> should have that meaning; we could pick any aspect of the current arrow
> >> function syntax and say "the 'fn' keyword means that".
> >>
> >>
> >>
> >>> On the other hand "use (*)" has no usages / or current meaning in the
> >>> language.
> >>
> >>
> >> This is a straw man argument. I could equally say that "fn() { } has no
> >> usages or current meaning in the language" - of course it doesn't, we
> >> haven't added it yet!
> >>
> >> The "function use() {}" part of "function use(*) {}" has a
> >> well-established meaning, and "*" to mean "everything" is a notation
> >> developers are likely to be very familiar with.
> >>
> >> The two disadvantages I see with using "fn" as proposed are:
> >>
> >> * Because it's shorter, people will decide it's the "better" version,
> when
> >> they don't actually need any variable capture. An explicit syntax like
> >> "use(*)" instead makes this a deliberate choice.
> >
> > And yet adding " use (*)" makes the syntax longer, which goes against
> one of
> > the goals many people have for it: to be shorter.
>
> I don't understand why this is a target in the first place. Shorter
> does not mean more readable, and readable is more important than
> writable.
>

I'm a bit confused on why "shorter" is such an important requirement as
well. We aren't in a situation where memory is at a premium and we have to
take shortcuts to get our code to fit in the available storage. I also
assume that none of us are such slow typers that there is a material
difference between the options. On top of that, most IDEs worth anything
have autocomplete options that make it moot.

I agree that shorter definitely does not always mean more readable. If so,
we'd be taught to give all of our functions and variables single character
names instead of names that were descriptive.

I'm totally in favor of auto capture with the fn() syntax, but I think the
fact that its shorter is not the best argument to support it.



>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2

[Olle Härstedt]

2021-03-25 16:02 GMT+01:00, Mike Schinkel :
>
>
>> On Mar 25, 2021, at 10:41 AM, Rowan Tommins 
>> wrote:
>>
>> On 25/03/2021 12:31, Nuno Maduro wrote:
>>
>>> The reason why we believe the vast majority of PHP Developers are going
>>> to
>>> appreciate this RFC is because multi-line short closures (aka
>>> Auto-capturing multi-statement closures) *are more simple, shorter to
>>> write, and prettier to read *— and the community love these changes as
>>> proven on "property promotions", "one-line short closures", etc.
>>
>>
>> My main point was that the RFC needs to spell out this argument, rather
>> than taking it for granted that everyone agrees on "those situations where
>> that is warranted".
>>
>> Most of the current text should be summarised in a "syntax choices"
>> section somewhere near the end. I would like to see much more space
>> devoted to:
>>
>> * Why we need this feature. What has changed since it was left out of the
>> arrow functions RFC? What problems is it addressing? Why do you think it
>> is the best approach to those problems?
>> * The exact semantics proposed: How will the variables to be captured be
>> determined? Will it distinguish variables which are written before they're
>> read, and if so how is that defined? Can auto-capturing closures be
>> nested, i.e. will "fn() { return fn() { echo $a; } }" capture $a from the
>> outermost scope? And so on...
>>
>>
>>> Besides, one advantage of this RFC is that it is consistent with the
>>> current syntax of the language and with the short-functions RFC[2]. For
>>> example, by proposing that "fn" keyword indicates a function will
>>> auto-capture variables, by value.
>>
>>
>> While it's a cute rationalisation, there's no intuitive reason why "fn"
>> should have that meaning; we could pick any aspect of the current arrow
>> function syntax and say "the 'fn' keyword means that".
>>
>>
>>
>>> On the other hand "use (*)" has no usages / or current meaning in the
>>> language.
>>
>>
>> This is a straw man argument. I could equally say that "fn() { } has no
>> usages or current meaning in the language" - of course it doesn't, we
>> haven't added it yet!
>>
>> The "function use() {}" part of "function use(*) {}" has a
>> well-established meaning, and "*" to mean "everything" is a notation
>> developers are likely to be very familiar with.
>>
>> The two disadvantages I see with using "fn" as proposed are:
>>
>> * Because it's shorter, people will decide it's the "better" version, when
>> they don't actually need any variable capture. An explicit syntax like
>> "use(*)" instead makes this a deliberate choice.
>
> And yet adding " use (*)" makes the syntax longer, which goes against one of
> the goals many people have for it: to be shorter.

I don't understand why this is a target in the first place. Shorter
does not mean more readable, and readable is more important than
writable.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2

[Deleu]

> * Because it's shorter, people will decide it's the "better" version,
> when they don't actually need any variable capture. An explicit syntax
> like "use(*)" instead makes this a deliberate choice.

Does this mean you agree that people (PHP users) are very likely to
like/enjoy/"think it's the better version", but you still object to it
because people will like the new syntax so much that they will use it even
when they don't need auto-capture?


On Thu, Mar 25, 2021 at 3:41 PM Rowan Tommins 
wrote:

> On 25/03/2021 12:31, Nuno Maduro wrote:
>
> > The reason why we believe the vast majority of PHP Developers are going
> to
> > appreciate this RFC is because multi-line short closures (aka
> > Auto-capturing multi-statement closures) *are more simple, shorter to
> > write, and prettier to read *— and the community love these changes as
> > proven on "property promotions", "one-line short closures", etc.
>
>
> My main point was that the RFC needs to spell out this argument, rather
> than taking it for granted that everyone agrees on "those situations
> where that is warranted".
>
> Most of the current text should be summarised in a "syntax choices"
> section somewhere near the end. I would like to see much more space
> devoted to:
>
> * Why we need this feature. What has changed since it was left out of
> the arrow functions RFC? What problems is it addressing? Why do you
> think it is the best approach to those problems?
> * The exact semantics proposed: How will the variables to be captured be
> determined? Will it distinguish variables which are written before
> they're read, and if so how is that defined? Can auto-capturing closures
> be nested, i.e. will "fn() { return fn() { echo $a; } }" capture $a from
> the outermost scope? And so on...
>
>
> > Besides, one advantage of this RFC is that it is consistent with the
> > current syntax of the language and with the short-functions RFC[2]. For
> > example, by proposing that "fn" keyword indicates a function will
> > auto-capture variables, by value.
>
>
> While it's a cute rationalisation, there's no intuitive reason why "fn"
> should have that meaning; we could pick any aspect of the current arrow
> function syntax and say "the 'fn' keyword means that".
>
>
>
> > On the other hand "use (*)" has no usages / or current meaning in the
> > language.
>
>
> This is a straw man argument. I could equally say that "fn() { } has no
> usages or current meaning in the language" - of course it doesn't, we
> haven't added it yet!
>
> The "function use() {}" part of "function use(*) {}" has a
> well-established meaning, and "*" to mean "everything" is a notation
> developers are likely to be very familiar with.
>
> The two disadvantages I see with using "fn" as proposed are:
>
> * Because it's shorter, people will decide it's the "better" version,
> when they don't actually need any variable capture. An explicit syntax
> like "use(*)" instead makes this a deliberate choice.
> * There is no obvious way to expand it to support any by-reference
> capture, which is something people have previously expressed a desire for.
>
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

-- 
Marco Aurélio Deleu

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2

[Mike Schinkel]

> On Mar 25, 2021, at 10:41 AM, Rowan Tommins  wrote:
> 
> On 25/03/2021 12:31, Nuno Maduro wrote:
> 
>> The reason why we believe the vast majority of PHP Developers are going to
>> appreciate this RFC is because multi-line short closures (aka
>> Auto-capturing multi-statement closures) *are more simple, shorter to
>> write, and prettier to read *— and the community love these changes as
>> proven on "property promotions", "one-line short closures", etc.
> 
> 
> My main point was that the RFC needs to spell out this argument, rather than 
> taking it for granted that everyone agrees on "those situations where that is 
> warranted".
> 
> Most of the current text should be summarised in a "syntax choices" section 
> somewhere near the end. I would like to see much more space devoted to:
> 
> * Why we need this feature. What has changed since it was left out of the 
> arrow functions RFC? What problems is it addressing? Why do you think it is 
> the best approach to those problems?
> * The exact semantics proposed: How will the variables to be captured be 
> determined? Will it distinguish variables which are written before they're 
> read, and if so how is that defined? Can auto-capturing closures be nested, 
> i.e. will "fn() { return fn() { echo $a; } }" capture $a from the outermost 
> scope? And so on...
> 
> 
>> Besides, one advantage of this RFC is that it is consistent with the
>> current syntax of the language and with the short-functions RFC[2]. For
>> example, by proposing that "fn" keyword indicates a function will
>> auto-capture variables, by value.
> 
> 
> While it's a cute rationalisation, there's no intuitive reason why "fn" 
> should have that meaning; we could pick any aspect of the current arrow 
> function syntax and say "the 'fn' keyword means that".
> 
> 
> 
>> On the other hand "use (*)" has no usages / or current meaning in the
>> language.
> 
> 
> This is a straw man argument. I could equally say that "fn() { } has no 
> usages or current meaning in the language" - of course it doesn't, we haven't 
> added it yet!
> 
> The "function use() {}" part of "function use(*) {}" has a well-established 
> meaning, and "*" to mean "everything" is a notation developers are likely to 
> be very familiar with.
> 
> The two disadvantages I see with using "fn" as proposed are:
> 
> * Because it's shorter, people will decide it's the "better" version, when 
> they don't actually need any variable capture. An explicit syntax like 
> "use(*)" instead makes this a deliberate choice.

And yet adding " use (*)" makes the syntax longer, which goes against one of 
the goals many people have for it: to be shorter.

> * There is no obvious way to expand it to support any by-reference capture, 
> which is something people have previously expressed a desire for.

Can you please clarify why "function(...) use(...) {...}" can't be their 
solution when someone needs by-reference capture?

-Mike

P.S. BTW, if we *had* to enable by-ref for "fn(...)" then I would argue it 
should be a terse syntax, e.g.:

$callable = fn()(&$foo) => $foo= bar();

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2

[Rowan Tommins]

On 25/03/2021 12:31, Nuno Maduro wrote:


The reason why we believe the vast majority of PHP Developers are going to
appreciate this RFC is because multi-line short closures (aka
Auto-capturing multi-statement closures) *are more simple, shorter to
write, and prettier to read *— and the community love these changes as
proven on "property promotions", "one-line short closures", etc.



My main point was that the RFC needs to spell out this argument, rather 
than taking it for granted that everyone agrees on "those situations 
where that is warranted".


Most of the current text should be summarised in a "syntax choices" 
section somewhere near the end. I would like to see much more space 
devoted to:


* Why we need this feature. What has changed since it was left out of 
the arrow functions RFC? What problems is it addressing? Why do you 
think it is the best approach to those problems?
* The exact semantics proposed: How will the variables to be captured be 
determined? Will it distinguish variables which are written before 
they're read, and if so how is that defined? Can auto-capturing closures 
be nested, i.e. will "fn() { return fn() { echo $a; } }" capture $a from 
the outermost scope? And so on...




Besides, one advantage of this RFC is that it is consistent with the
current syntax of the language and with the short-functions RFC[2]. For
example, by proposing that "fn" keyword indicates a function will
auto-capture variables, by value.



While it's a cute rationalisation, there's no intuitive reason why "fn" 
should have that meaning; we could pick any aspect of the current arrow 
function syntax and say "the 'fn' keyword means that".





On the other hand "use (*)" has no usages / or current meaning in the
language.



This is a straw man argument. I could equally say that "fn() { } has no 
usages or current meaning in the language" - of course it doesn't, we 
haven't added it yet!


The "function use() {}" part of "function use(*) {}" has a 
well-established meaning, and "*" to mean "everything" is a notation 
developers are likely to be very familiar with.


The two disadvantages I see with using "fn" as proposed are:

* Because it's shorter, people will decide it's the "better" version, 
when they don't actually need any variable capture. An explicit syntax 
like "use(*)" instead makes this a deliberate choice.
* There is no obvious way to expand it to support any by-reference 
capture, which is something people have previously expressed a desire for.



Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures andshortfunctions take 2

[Olle Härstedt]

2021-03-25 15:23 GMT+01:00, Christian Schneider :
> Am 25.03.2021 um 14:29 schrieb Mark Randall :
>> On 25/03/2021 09:28, Rowan Tommins wrote:
>>> That's not quite what I meant. I meant that you can't say "capture by
>>> default, but this variable is definitely local".
>>
>> I think if there's one argument against, this would be it, but IMHO it is
>> a weakness in PHP as a whole.
>
> I'm not sure if I misunderstand what you're saying but to me it is one of
> the greatest things about PHP that everything is local by default (minus a
> narrow set of well-known and easily enough recognizable things).
>
>> The solution would be adding JS-like let / const statements. Which would
>> be a benefit to other things too.
>
>
> I disagree that this is the solution. I think JS had to add var and later
> let because of the unfortunate decision to have C-like scoping rules.
> Making scoping in PHP more complex to be able to repeat this mistake in some
> form seems ill-advised to me.
>
> - Chris

You could make the change that *all* variables are now block-scoped,
not function-scoped. That would make auto-capture less dangerous, but
I don't know how much code it would break.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures andshortfunctions take 2

[Christian Schneider]

Am 25.03.2021 um 14:29 schrieb Mark Randall :
> On 25/03/2021 09:28, Rowan Tommins wrote:
>> That's not quite what I meant. I meant that you can't say "capture by 
>> default, but this variable is definitely local".
> 
> I think if there's one argument against, this would be it, but IMHO it is a 
> weakness in PHP as a whole.

I'm not sure if I misunderstand what you're saying but to me it is one of the 
greatest things about PHP that everything is local by default (minus a narrow 
set of well-known and easily enough recognizable things).

> The solution would be adding JS-like let / const statements. Which would be a 
> benefit to other things too.


I disagree that this is the solution. I think JS had to add var and later let 
because of the unfortunate decision to have C-like scoping rules.
Making scoping in PHP more complex to be able to repeat this mistake in some 
form seems ill-advised to me.

- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures andshortfunctions take 2

[Mike Schinkel]

> On Mar 25, 2021, at 9:54 AM, Olle Härstedt  wrote:
> 
> 2021-03-25 14:29 GMT+01:00, Mark Randall :
>> On 25/03/2021 09:28, Rowan Tommins wrote:
>>> That's not quite what I meant. I meant that you can't say "capture by
>>> default, but this variable is definitely local".
>> 
>> I think if there's one argument against, this would be it, but IMHO it
>> is a weakness in PHP as a whole.
>> 
>> The solution would be adding JS-like let / const statements. Which would
>> be a benefit to other things too.
> 
> JS does not support "definitely local". No language does, AFAIK.
> Unless you count value types.

Actually, at least a few languages on this list have "definitely local" 
variables:

https://en.wikipedia.org/wiki/List_of_programming_languages

I have had in-depth experience with two of them, the former of which was a 
dynamic language and both support auto-capturing closures: 

- Clipper 
- GoLang

#fwiw

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Auto-capture multi-line closuresandshortfunctions take 2

[Mark Randall]

On 25/03/2021 13:54, Olle Härstedt wrote:

JS does not support "definitely local". No language does, AFAIK.
Unless you count value types.


We were both refering to block-level variables, which most languages do.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures andshortfunctions take 2

[Olle Härstedt]

2021-03-25 14:29 GMT+01:00, Mark Randall :
> On 25/03/2021 09:28, Rowan Tommins wrote:
>> That's not quite what I meant. I meant that you can't say "capture by
>> default, but this variable is definitely local".
>
> I think if there's one argument against, this would be it, but IMHO it
> is a weakness in PHP as a whole.
>
> The solution would be adding JS-like let / const statements. Which would
> be a benefit to other things too.

JS does not support "definitely local". No language does, AFAIK.
Unless you count value types.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures andshortfunctions take 2

[Mark Randall]

On 25/03/2021 09:28, Rowan Tommins wrote:
That's not quite what I meant. I meant that you can't say "capture by 
default, but this variable is definitely local".


I think if there's one argument against, this would be it, but IMHO it 
is a weakness in PHP as a whole.


The solution would be adding JS-like let / const statements. Which would 
be a benefit to other things too.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2

[Olle Härstedt]

I feel like some of these examples would be better covered by command
object pattern and data-transaction objects, instead of FP idioms.
wrap_in_buffer pretty clearly so.

2021-03-25 10:28 GMT+01:00, Rowan Tommins :
> On 25/03/2021 04:12, Mike Schinkel wrote:
>
>> Actually, there is a way to declare a local variable.  Use the long
>> function syntax instead as there is no proposal to deprecate it.
>
> That's not quite what I meant. I meant that you can't say "capture by
> default, but this variable is definitely local".
>
> I'm guessing maybe "$foo = null;" at the top of the function would stop
> it auto-capturing, but the semantics of what exactly gets captured
> aren't spelled out in the RFC. That really needs to be added IMO.
>
>
>> Instead of using array_filter() with a side-effect free closure, I use a
>> for loop because it is easier to reason about visually.
>
>
> Is that a bad thing? In many cases it's probably more efficient, and
> easier to read.
>
>
>
>
>> It is not clear to me from reading the PEP how a "with" statement obviates
>> the benefit of variable auto-capture? Maybe because I don't "think" in
>> Python, so from reading their examples I cannot see how this relates?
>
>
> I didn't mean to say that the "with" statement would replace closures in
> general, but it would make them unnecessary *for some specific use
> cases*. You mentioned:
>
>  > prime examples are database transactions and using throw-aware
> buffering handlers.
>
> If your current code looks something like this:
>
> wrap_in_buffer(function($transaction) use ($to, $library, $thread,
> $author, $title, $library_name, $top_post) {
>  doSomething($to, $library, $thread);
>  andThenSomethingElse($author, $title, $library_name, $top_post);
> });
>
> That's a perfect use case for a Context Manager:
>
> with ( wrap_in_buffer() ) {
>  doSomething($to, $library, $thread);
>  andThenSomethingElse($author, $title, $library_name, $top_post);
> }
>
> There's no callback, so no need to capture anything, and the
> implementation of all the try-catch-finally logic would be baked into
> the language, so the implementation of wrap_in_buffer() would also be
> much simpler.
>
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2

[Olle Härstedt]

> prettier to read

Are they though? Because if it implicitly captures anything in scope,
there are more lines to read to figure out what's actually captured.

2021-03-25 13:31 GMT+01:00, Nuno Maduro :
> Hi,
>
> Thank you for the feedback on this thread so far. Programmers are
> opinionated, therefore you will find developers that see themselves using
> this RFC and others who don't. Just like "Fibers", "Type-hints", or any
> other feature in the language really.
>
> The reason why we believe the vast majority of PHP Developers are going to
> appreciate this RFC is because multi-line short closures (aka
> Auto-capturing multi-statement closures) *are more simple, shorter to
> write, and prettier to read *— and the community love these changes as
> proven on "property promotions", "one-line short closures", etc. [1]
>
> Besides, one advantage of this RFC is that it is consistent with the
> current syntax of the language and with the short-functions RFC[2]. For
> example, by proposing that "fn" keyword indicates a function will
> auto-capture variables, by value. And, the "=>" sigil always means
> "evaluates to the expression on the right" in all circumstances - one-line
> short closures, named functions, arrays, and match() already follow these
> patterns. [3]
>
> On the other hand "use (*)" has no usages / or current meaning in the
> language.
>
> Thanks,
> Nuno.
>
> [1] Pretty much "Brent Roose" have said here:
> https://externals.io/email/112010/source
> [2] https://wiki.php.net/rfc/short-functions
> [3] Check "Auto-capture multi-statement closures" -
> https://wiki.php.net/rfc/auto-capture-closure.
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2

[Mike Schinkel]

> On Mar 25, 2021, at 5:28 AM, Rowan Tommins  wrote:
> 
> On 25/03/2021 04:12, Mike Schinkel wrote:
> 
>> Actually, there is a way to declare a local variable.  Use the long function 
>> syntax instead as there is no proposal to deprecate it.
> 
> That's not quite what I meant. I meant that you can't say "capture by 
> default, but this variable is definitely local".


Yes I can see you want a way to declare a local in an auto-capturing fn(), but 
respectfully I do not see why using the function() syntax is not a viable 
alternate solution when and if you want to explicitly not capture a variable.

I said "want" because you will never *need* to as you can always use a variable 
name that is not in the outer scope. 

And yes I know, someone may come along later and add a named variable in the 
outer scope that matches your implicit local variable's name and potentially 
break your code, but again if that is a concern why can't you just use 
function() instead of fn()?  And wouldn't they actually be breaking their code 
(the outer code) if they did this?

Respectfully, you seem to be calling out a problem for which there is a 
tailor-designed solution explicitly recommended in the RFC. How can function() 
not address your stated concern?


> I'm guessing maybe "$foo = null;" at the top of the function would stop it 
> auto-capturing, but the semantics of what exactly gets captured aren't 
> spelled out in the RFC. That really needs to be added IMO.
> 
> 
>> Instead of using array_filter() with a side-effect free closure, I use a for 
>> loop because it is easier to reason about visually.
> 
> Is that a bad thing? In many cases it's probably more efficient, and easier 
> to read.


Depends on what your priorities are.  If you priorities are coding in the 
absolute most efficient manner and/or with the most clarity, no it is probably 
not a bad thing.

But if your priorities are coding in the most robust manner where your code is 
free from side-effects by design — in a functional style —  and the performance 
difference is insignificant, then yes it is a bad thing. 

And at least one of the pair of RFCs spell out this motivation to allow for 
more functional style explicitly. 


>> It is not clear to me from reading the PEP how a "with" statement obviates 
>> the benefit of variable auto-capture? Maybe because I don't "think" in 
>> Python, so from reading their examples I cannot see how this relates?
> 
> I didn't mean to say that the "with" statement would replace closures in 
> general, but it would make them unnecessary *for some specific use cases*.


Respectfully again, to argue a use-case could be addressed in a different way 
than proposed by the RFC when that different way uses a hypothetical language 
feature that AFAIK does not have an RFC currently under consideration rings 
hollow to me.

Minimally I would expect you to at least first float the hypothetical on the 
list to see if there is appetite for it rather than just using is idea to snipe 
at an RFC that many people appear to support.


> You mentioned:
> 
> > prime examples are database transactions and using throw-aware buffering 
> > handlers.


Actually, I did not provide that example. Other people did.  

What I stated was I had other use-cases that concerned me more than 
transactions, which I already explained in my email. 

However, in no way do I mean to argue against their value for other developers 
who mentioned them.


> If your current code looks something like this:
> 
> wrap_in_buffer(function($transaction) use ($to, $library, $thread, $author, 
> $title, $library_name, $top_post) {
> doSomething($to, $library, $thread);
> andThenSomethingElse($author, $title, $library_name, $top_post);
> });
> 
> That's a perfect use case for a Context Manager:
> 
> with ( wrap_in_buffer() ) {
> doSomething($to, $library, $thread);
> andThenSomethingElse($author, $title, $library_name, $top_post);
> }
> 
> There's no callback, so no need to capture anything, and the implementation 
> of all the try-catch-finally logic would be baked into the language, so the 
> implementation of wrap_in_buffer() would also be much simpler.


But thanks for clarifying with examples, because I did ask for that.

That said, "with" is still hypothetical.  Are you planning to champion its 
inclusion into PHP with a discussion and then follow up RFC?

-Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2

[Nuno Maduro]

Hi,

Thank you for the feedback on this thread so far. Programmers are
opinionated, therefore you will find developers that see themselves using
this RFC and others who don't. Just like "Fibers", "Type-hints", or any
other feature in the language really.

The reason why we believe the vast majority of PHP Developers are going to
appreciate this RFC is because multi-line short closures (aka
Auto-capturing multi-statement closures) *are more simple, shorter to
write, and prettier to read *— and the community love these changes as
proven on "property promotions", "one-line short closures", etc. [1]

Besides, one advantage of this RFC is that it is consistent with the
current syntax of the language and with the short-functions RFC[2]. For
example, by proposing that "fn" keyword indicates a function will
auto-capture variables, by value. And, the "=>" sigil always means
"evaluates to the expression on the right" in all circumstances - one-line
short closures, named functions, arrays, and match() already follow these
patterns. [3]

On the other hand "use (*)" has no usages / or current meaning in the
language.

Thanks,
Nuno.

[1] Pretty much "Brent Roose" have said here:
https://externals.io/email/112010/source
[2] https://wiki.php.net/rfc/short-functions
[3] Check "Auto-capture multi-statement closures" -
https://wiki.php.net/rfc/auto-capture-closure.

Re: [PHP-DEV] [RFC] Short functions, take 2

[Guilliam Xavier]

On Thu, Mar 25, 2021 at 4:23 AM Levi Morrison via internals <
internals@lists.php.net> wrote:

> [...]
> Instead of writing this:
>
> ```
> class A
> {
>   public function method($arg1)
>   {
> return expr($arg1);
>   }
> }
> ```
>
> I can write this:
>
> ```
> class A {
>   function method($arg1) { return expr($arg1); }
> }
> ```
>

For what it's worth (probably not much), when fiddling with quick test code
samples (e.g. on 3v4l with "quick preview"), more than once I have written
things like this:

```
class A {
  function method($arg1) { expr($arg1); }
}
```

i.e. I initially forgot the "return " (and had to go back and add it).  I
would surely not have this problem anymore with this:

```
class A {
  function method($arg1) => expr($arg1);
}
```

(It also seems I don't have this problem when writing a return on its own
line :/)

Regards,

-- 
Guilliam Xavier

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and shortfunctions take 2

[Rowan Tommins]

On 25/03/2021 04:12, Mike Schinkel wrote:


Actually, there is a way to declare a local variable.  Use the long function 
syntax instead as there is no proposal to deprecate it.


That's not quite what I meant. I meant that you can't say "capture by 
default, but this variable is definitely local".


I'm guessing maybe "$foo = null;" at the top of the function would stop 
it auto-capturing, but the semantics of what exactly gets captured 
aren't spelled out in the RFC. That really needs to be added IMO.




Instead of using array_filter() with a side-effect free closure, I use a for 
loop because it is easier to reason about visually.



Is that a bad thing? In many cases it's probably more efficient, and 
easier to read.






It is not clear to me from reading the PEP how a "with" statement obviates the benefit of 
variable auto-capture? Maybe because I don't "think" in Python, so from reading their 
examples I cannot see how this relates?



I didn't mean to say that the "with" statement would replace closures in 
general, but it would make them unnecessary *for some specific use 
cases*. You mentioned:


> prime examples are database transactions and using throw-aware 
buffering handlers.


If your current code looks something like this:

wrap_in_buffer(function($transaction) use ($to, $library, $thread, 
$author, $title, $library_name, $top_post) {

    doSomething($to, $library, $thread);
    andThenSomethingElse($author, $title, $library_name, $top_post);
});

That's a perfect use case for a Context Manager:

with ( wrap_in_buffer() ) {
    doSomething($to, $library, $thread);
    andThenSomethingElse($author, $title, $library_name, $top_post);
}

There's no callback, so no need to capture anything, and the 
implementation of all the try-catch-finally logic would be baked into 
the language, so the implementation of wrap_in_buffer() would also be 
much simpler.



Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: Release Managers for PHP 8.1

[Sergey Panteleev]

Hi there,

I would like to help as a newbie volunteer too.
If possible, my hat's in the ring.

—
wbr,
Sergey Panteleev



signature.asc
Description: PGP signature